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

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

Greg A. Woods wrote:
> I think I do see what you mean now though -- rsync may have already
> scanned some portion of the tree and thus not have seen the change
> having happened to the first file being affected, but by the time it
> gets to the second file, that file has changed and it will update it.

Yes, exactly.

> I guess the question is:  How long of a time span is there on the files
> affected by the "average" commit?  If it's only about a second or even
> two for most multi-file commits then any using any random timestamp from
> just before the rsync starts really will be quite reasonable for doing
> automated builds.  After all the repository isn't really that busy.

Yes, it's usually only a second or two.

> > You don't even need multi-file commits for this to happen.  I saw one
> > case where two separate commits were made in different parts of the
> > tree, more than two minutes apart, and rsync picked up the later one
> > but not the earlier one.
> 
> In theory multiple commits of related changes shouldn't happen -- that's
> the part I mentioned previously where I expressed my opinion that I
> think NetBSD developers are on the whole really quite good at actually
> using single commits per set of related changes.

In the case I mentioned, the first commit was actually fully
self-contained, such that the tree was in a buildable state after
applying it.  The second commit then depended on the first one being
present.  There is absolutely nothing wrong with making a commit that
is complete and correct in itself and then a second commit that
depends on it; that's just how incremental development is done.

Anyawy, this whole discussion of the relative merits of single versus
multiple commits is irrelevant to the specific technical issue I'm
trying to solve, that of rsync returning a result that is not a
consistent snapshot of whatever the developer committed, good or bad.
The only reason I brought up the two-commit case was because it shows
that the file scan on the server can in fact take on the order of
minutes.
-- 
Andreas Gustafsson, gson%gson.org@localhost