[Buildbot-devel] configuration help

[Brian Warner]

> Documentation suggests that a single change set can only be associated with
> a single branch. Is that correct ?

Yes. "One branch per Change" is a pretty fundamental concept in the buildbot
architecture, so I'm more willing to have the branch-determination happen in
a new place than to try and change the buildbot to accomodate some crazy
notion of multiple-branch Changes.

> Given that subversion itself doesn't have any concept of a branch, and that
> branches are almost arbitrarily associated with subdirectories, that would
> suggest that the 'branch detection' mechanism we are discussing should indeed
> happen inside svn_buildbot.py, so it can then generate one notification
> per branch, even for a single checkin / revision.

Well, it could go either way, in svn_buildbot.py or in the buildmaster
itself. The advantage of putting it in the buildmaster's master.cfg file is
that it becomes easier for the buildmaster admin to update it to reflect
changes in repository layout or branch-naming policy. The advantage of
putting it in svn_buildbot.py is that the policy then lies "closer" to the
repository. In some sense, the branch-naming policy is "owned" by the SVN
admin, not the buildmaster admin, and other tools (mailing lists, things like
Trac, other release-automation scripts) might want to know what branch is
being touched too. So that makes me want to have the branch-naming policy
expressed by something outside of buildbot, and since raw SVN doesn't offer
it internally, it seems to want to go somewhere between the repository and
the buildbot.

svn_buildbot.py is the only such place right now, but even that is a little
too buildbot-specific. The trouble is that none of these other hypothetical
tools (here I'm imagining each branch having a separate 'foo-commits' mailing
list or something) are going to take advantage of whatever branch-determining
logic lives inside svn_buildbot.py . Maybe there should be some tool that can
be run from within post-commit scripts that queries something inside the
repository for the branch-naming policy. Hmm, like maybe a script that's
checked into the repository, at some well-known location (like the root), and
this tool would grab a copy (with svn cat), save it somewhere, execute it,
passing it the repository-relative filename, and expect it to emit a branch
name and branch-relative filename back out. Or maybe this script could
actually be some python code that's eval()'ed inline. Or maybe the branch
name should be a subversion property on the directory that forms the "top" of
any particular branch, and the tool should recursively do 'svn propget
branchname' on each successive parent directory of the file being examined
until it gets a hit, and then split the filename at that point.

Ooh, I think I like that last one. That would keep the branch-naming policy
in the realm of the svn admin, as opposed to buried in some other tool that
might not get updated quickly enough to stay in sync with policy changes. It
would also provide a clear technique for other tools to determine the branch
name.

But.. surely the SVN folks have addressed this issue before? I know the
svnbook docs are deliberately vague about branch naming policy (they don't
want to enforce any particular style), but maybe they've come up with some
recommended practices on their mailing list?

> I agree with Chris that a little configuration file to do that would be
> nice, though I would choose a more pythonic approach. ;-)

I'm inclined to agree. I'm not smart enough to invent a (good) new language
for expressing things like that.. I'd stick to something nice and safe like
python :).

cheers,
 -Brian