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

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

Alan Barrett wrote:
> You can't really, but you could check whether there were any 
> changes very close to the time when you made the snapshot, and 
> assume that such changes may be incomplete.  You could also assume 
> that changes that have not yet appeared in the source-changes 
> mailing list may be incomplete.
> 
> When you suspect you may have incomplete changes, I can think of 
> two reasonably simple strategies to deal with that:
> 
> 1. Don't perform the build now.  Instead, make another snapshot, 
> and loop until you get a snapshot without any changes that are so 
> recent that there's a risk that they might be incomplete.
> 
> 2. Backtrack through the list of changes until you find a quiet 
> period that lasts long enough for comfort.  Use a "-D" argument 
> that specifies a time within the quiet period.

Yes, heuristics like these, including the similar ones suggested by
Christos, Joerg, and Greg, would probably work, at least most of the
time.  I suspect I will end up having to implement something like
this, even though it irks me that I and everyone else who has a need
to mirror the repository has to work around these issues separately,
instead of the project providing the fundamental service of making
the repository publicly available, for some even halfway consistent
definition of "the".

> I seldom see more than a 1 second gap in the commit times for 
> files that belong to the same logical commit, so looking for a 5 
> second quiet period would probably be enough.

Alas, five seconds is not even nearly enough, because the main issue
is not the time it takes to do a commit, but the time it takes to
rsync the entire repository.
-- 
Andreas Gustafsson, gson%gson.org@localhost