At Sun, 13 Nov 2011 15:29:31 +0200, Andreas Gustafsson
<gson%gson.org@localhost> wrote:
Subject: Re: Automated report: NetBSD-current/i386 build failure
>
> Greg A. Woods wrote:
> >
> > 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.
The use of the e-mail feed is simply a very rough work-around that might
avoid having to create any new features in the master CVS repository.
I.e. the "existing tools" approach.
A better solution would indeed be to log markers of quiescent times and
to include this log in the repository such that every user of the
repository could take advantage of it.
Once upon a time it was suggested that it might be possible to release
the scripts that are used in the master repository. This is an example
of where making them public and open-source would allow someone else to
design, implement, and test changes which could provide new features
such as this.
> 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.
I can't claim to be very much of an expert in statistics, but in
practice I don't think that'll make a significant enough difference to
the resulting "consistency" of an update. As far as I can see one
random timestamp is pretty much identical to any other random timestamp
in this regard.
I.e. the statistical likelihood that an rsync will update some files
which are changed during a commit and not all those changed during a
commit is, I would guess, almost identical to the likelihood that any
random date and time will occur in the middle of a sizable enough commit
where such consistency would actually matter. This is because I think
the part of the rsync process which can actually be affected by a commit
in progress is relatively short-lived and so it's time-span doesn't
really make it that much more likely that it might occur in the middle
of a commit which could affect the consistency enough to break a build.
Indeed the difference between just doing a plain "cvs update" after
rsync finishes vs. doing an update with some timestamp from just before
the rsync started may simply not be noticeable enough in the NetBSD
repository because it isn't really all that busy, and especially not
usually so busy with big enough commits which must be complete in order
to result in a "successful" build.
All that said though I still don't know if it would be worthwhile to try
to implement these "quiescent markers" I describe. The real problem
with CVS isn't that it doesn't include this feature by default since it
could clearly be built on the existing foundation (and there have been a
plethora of discussions about this issue in CVS circles for nearly a
decade now). The real problem with CVS, in this respect, is that it's
too expensive to create and make good use of branches (which can be a
mechanism for creating change sets which is much less prone to human
error). Meanwhile in practice it's not such a big deal and we get by
quite well without having atomic change sets, just as CVS long ago
proved that you can get by quite well without doing strict locking in a
version control system.
--
Greg A. Woods
Planix, Inc.
<woods%planix.com@localhost> +1 250 762-7675 http://www.planix.com/
Attachment:
pgpKv4n_Chfrq.pgp
Description: PGP signature