[Buildbot-devel] Behavior expected from SVN master side source step

J Hegge qdev at oceanhills.net
Thu Apr 5 16:01:40 UTC 2012

On Apr 3, 2012, at 5:55 PM, Tom Prince wrote:

> On Tue, 3 Apr 2012 08:32:45 -0400, Charles Lepple <clepple at gmail.com> wrote:
>> On Apr 1, 2012, at 12:18 PM, Dustin J. Mitchell wrote:
>> For what it's worth, I usually end up including a custom
>> split_file_branches() function for the change source that returns the
>> text 'trunk' instead of None for the default branch, so I might not be
>> seeing all of the potential problems that might arise from using
>> WithProperties. Also, this means we have to explicitly specify
>> 'branches/foo' instead of just 'foo' in the force build page for NUT -
>> not sure how other people are handling that in their
>> Subversion+Buildbot setup, but it Works For Me (tm).
> For what it is worth, we are trying to deprecate the
> None-is-default-branch behavior. I think representing branches as
> 'bracnhes/foo' is a sensible thing to do. I'm curious if when doing
> that, if people actually have repositories that are structured anything
> other thand <repo>/<branch>? The only other structure I have seen
> suggested is <repo>/<branch>/<project>, but I don't know if there is any
> signficant use of that.
> If people are doing <repo>/<branch>/<project>, would it be reasonable to
> use '<branch>/<project>' as the branch name, so having things like
> 'trunk/projectA' and 'trunk/projectB' as branch names. This would mean
> we could always get the url to checkout by appending the branch to repo.
> Opinions?

We similarly use SVN with not too many assumptions on the branch vs. trunk pathing.   I have CI, nightly and production/release builds.  CI builds with ChangeFilters (to split platforms) whereas nightly & production use sendchange.   The CI builds are easy but the production builds require me to build up the path for branch vs. trunk builds.  

Now, we do have a structure that is technically  <repo>/<branch>/<project> but that isn't the whole story.   Packaging releases makes for some messy work but I just use WithProperties to send amplifying data to steps.   My point is, I don't think changing to eliminate the strange repourl vs. baseurl bit matters, I'd rather just see it simplified.   I've not dug into the SVN code that I added for SVN tagging for some time but I remember scratching my head over the computeRepositoryURL() business.   Some of the magic code you are referring to?

I'm also using 0.8.2 at the moment, looking finally to upgrade to 0.8.6/0.8.7.   I decided to wait out the master-side changes and save the work while very busy elsewhere.   In fact, now that I'm looking over the upgrade of our build system we've also decided to give git another look.   We are currently constrained by some horrible Windows source indexing tools in Perl (limited SCM support) but who's surprised to hear that?

So, we have an ungainly source tree, not ideal for Buildbot's steps but I've not hacked too much to adapt.  I always assume a trunk build will be reasonable and I'll do the work to get Buildbot handling the correct branch path.   I like to keep that work out of Buildbot, leaving its logic more lean.   Go with the changes.

More information about the devel mailing list