Re: Automated report: NetBSD-current/i386 build failure

[Andreas Gustafsson <gson%gson.org@localhost>]

Thor Lancelot Simon wrote:
> On Fri, Nov 11, 2011 at 11:33:10PM +0200, Andreas Gustafsson wrote:
> > 
> > Your assumption is correct, and the next build did succeed.  Sorry about
> > the false alarm.  If only there was a way to mirror the repository that
> > would guarantee a consistent snapshot...
> 
> Not really possible; CVS does not have changelists.  You can't do any
> better than it does for the developers themselves!

I think there are two distinct problems here.  The lack of change sets
in CVS essentially means that writes to the repository are not atomic,
while the use of rsync for mirroring means that reads of the
repository are not atomic.  The false alarms in the auto-builds have
not been caused by the non-atomic writes (commits), but by the
non-atomic reads (rsync).

A typical case would be a commit involving a .c file and a .h file in
different directories.  Such a commit will usually complete in a
second or two.  Mirroring the repository using rsync, on the other
hand, can take several minutes.  While it is possible for the rsync to
happen between the commit of the .c file and the commit of the .h
file, it is much more likely for the commit to happen between the
rsync of the .c file and the rsync of the .h file, and that's in 
fact what has been happening.

So whan I'm talking about getting a consistent snapshot of the
repository, I'm really talking about read atomicity only.  I'm willing
to take the small risk of snapshotting the repository while it is in
the middle of a commit, but I'd like to eliminate the much greater
risk of a commit happening in the middle of mirroring.  There is no
fundamental reason why this couldn't be done despite the broken
semantics of CVS, but that still doesn't mean it's easy...
-- 
Andreas Gustafsson, gson%gson.org@localhost