Re: kernel.bkbits.net off the air

[Andrea Arcangeli <andrea@suse.de>]

On Mon, Nov 10, 2003 at 11:34:18PM -0800, Davide Libenzi wrote:
> On Mon, 10 Nov 2003, jw schultz wrote:
> 
> > If not you can test the directory.
> > 
> >         ls -l $CVSROOT/CVSROOT >$TMPFILE.start
> >         touch $TMPFILE.test
> > 
> >         until diff -q $TMPFILE.start $TMPFILE.test >/dev/null
> >         do
> > 		ls -l $CVSROOT/CVSROOT >$TMPFILE.start
> >                 rsync .....
> >                 ls -l $CVSROOT/CVSROOT >$TMPFILE.test
> >         done
> >         rm -f $TMPFILE.start $TMPFILE.test
> 
> It does not work either. If CVSROOT files are updated at the end, you can 
> still fetch some new files and be able to fetch the old CVSROOT before the 
> update process will be able to do it. I believe that the LOCK file idea 
> should work pretty nicely. The update process goes like:
> 
> create LOCK
> update repo
> remove LOCK
> 
> While the client can simply:
> 
> do
>     rsync
> while exist LOCK

that can't work either, the client can't take the lock, rsync is a
readonly thing. the create lock update repo, remove lock will all three
run during the client rsync. the "exist LOCK" will never notice.

unless you want to use snapshots etc.. the seq lock is the only viable
way to checkout coherent with rsync.

hope this isn't going too offtopic for l-k though.