Branches in changes (was Re: [Buildbot-devel] configuration help)

[Chris Leishman]

On Thu, Nov 24, 2005 at 03:50:51PM -0800, Brian Warner wrote:
<snip> 
> Hmm. So far I've been assuming that repository branch policy is part of the
> repository, not part of the buildbot, but I can see how it would be more
> convenient to be able to specify it inside the master.cfg file. While working
> on the build-on-branch feature, I started at the end (on the buildslaves) and
> worked my way back "upstream" towards the ChangeSources. Therefore I was able
> to keep putting off the decision about where the branch names come from in
> the first place. This issue of whether branches are calculated inside the
> ChangeSource or back in the sender (svn_buildbot.py) is a reflection of this
> deferred architecture decision (i.e., of my laziness :).
<snip>

Thinking about it I can see that this would be nice for subversions, but
other VCS systems (eg. CVS) cant tell the branch from the file path and
would have to pass the 'branch' through seperately.

So keeping the 'branch' close to the repository would make sense in a
uniform model.

I'm wondering, however, if the 'branch' should not actually be
associated with the file - not with the change.  This would, of course,
mean having a list of tuples in the change, of the form:

  ((file, branch), (file, branch), ...)

That way you know all the branches that would be affected by a
particular change implicitly.  You could also do some grouping if it
made it a bit nicer:

  ((branch, (file, ...)), (branch, (file, ...)), ...)

That might not be necessary in the actual datastructures, but on
the status displays of the change it could be nicer.

Just some ideas.

cheers,
chris