[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Automated report: NetBSD-current/i386 build failure
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
Andreas Gustafsson, gson%gson.org@localhost
Main Index |
Thread Index |