[Buildbot-devel] Slightly better paper trail?

[Charles Lepple]

On Thu, Jul 30, 2009 at 1:11 PM, Marcus Lindblom<macke at yar.nu> wrote:
> Charles Lepple wrote:
>> On Tue, Jul 28, 2009 at 1:52 PM, Doug Latornell<doug at sadahome.ca> wrote:
>>> I think you could get the behaviour you want by reducing the value of the
>>> treeStableTimer when you create the Scheduler instance.  IIRC, it defaults
>>> to 20 minutes.  Not sure if setting it to zero would cause a build per
>>> commit, but it's worth a try.
>>
>> That will work until someone commits two (or more) changes in less
>> time than it takes to build the first change.
>
> Actully no. It queues up another build. I've seen this happen several
> times, with SVN and a timer of 2 minutes, where the build takes 10-15
> minutes. Sometimes 3-4 builds are in queue due to incomming commits
> during a build.

The ticket I cited talks about combining incoming change objects if
they are "compatible". Several changes may be queued, but if they are
on the same branch, the default action is to combine them right when
the next build starts.

> I think SVN might work well here. Change-hooks for DVCS:s (Mercurial for
> one) tend to send all pushed commits as a single change, thus not
> allowing for this. (that could of course be fixed, rather easily methinks)

I can't speak for other systems, but I think there are several places
in the Buildbot code where separate SVN commits can get combined (the
SVN poller, the treeStable timer, and the code referenced by that
ticket).

-- 
- Charles Lepple