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

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

Greg A. Woods wrote:
> To the best of my memory I've never seen CVS trip over a file which was
> "corrupted" because rsync caught it in the middle of being updated,
> either in the reports from my automated updates, or from my random
> manual updates.

Neither have I; the problem I'm having is not corruption of any
individual file involved in a commit, but ending up with a respository
copy where some of the files involved in a commit have been
(correctly) updated and others have not.

> So, to create/update checkout of a module such that you get as stable as
> possible set of sources in between any commit activity one need only
> specify a date and time that's somewhere mid-way between when the last
> two sufficiently separated(*) source-changes messages were generated
> just before the rsync started.  That's as perfect as can be with the
> existing tools(**) I think, and you can't do any better than the
> developers who are feeding the changes into the repository anyway.

I'm sure that would work in principle, and it's a nice thought
experiment with respect to what's theoretically possible, but as a
practical matter, having the build scripts read email seems like an
overly complicated and fragile solution.

In practice, I think the simple change of doing date-based checkouts
only from times prior to the start of the rsync, minus a small safety
margin to cover any clock skew between the systems and the time it
takes to do the cvs-to-anoncvs push, should work well enough to fix
the problem at hand.  I'm already testing some code changes to do
that.
-- 
Andreas Gustafsson, gson%gson.org@localhost