lkml.org 
[lkml]   [2003]   [Nov]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: kernel.bkbits.net off the air
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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:58    [from the cache]
©2003-2011 Jasper Spaans