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

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

Greg A. Woods wrote:
> 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.

+1

> 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.

I don't agree that "the part of the rsync process which can actually
be affected by a commit in progress is relatively short-lived".  Even
small commits often affect files spread across multiple directories
that are arbitrarily far apart in the repository tree, such as a
header file in src/include and some source files in src/usr.bin, or a
newly added file to be installed and its corresponding entry under
src/distrib/set/lists, so the time between rsync visiting the two will
be a sizable fraction of the time it takes to scan the entire tree.

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.
-- 
Andreas Gustafsson, gson%gson.org@localhost