[Buildbot-devel] P4 with different branches

[Brian Warner]

> From: Minesh Patel <minesh11 at yahoo.com>
> Subject: [Buildbot-devel] P4 with different branches
> Date: Wed, 29 Jun 2005 23:26:04 -0700 (PDT)

[Brian continues his post-trip catch-up-on-week-old-buildbot-mail campaign]

> I have a setup with a p4 with branches as //depot/x and //depot/y. I
> created a source of "//depot". Now if I create two builders(b1 and b2)with
> different respective factories and each factory is using isFileImportant
> method with "//depot/x " for b1 and "//depot/y" for b2. Will this work?
> Will I get updates on both the builders and trigger builds? Do I need a
> master per branch until the build-on-branch (b-o-b) is complete?

It depends upon the ChangeSource you're using. All ChangeSources emit
relative filenames, but the question of "relative to what" is determined by
how the source is fed and by what kind of "prefix" it is using. The sources
generally require that whatever more-or-less absolute filename they are
presented with start with the "prefix" string, otherwise it is ignored. The
source then removes that prefix from the filename and passes it on to the
Builders. The Builders (in their isFileImportant method) only deal with these
relative filenames.

So, until the Scheduler stuff is done, there are two approaches you can take:

 1: use a separate master for each branch. In this case, the ChangeSource
 should be configured to require/strip a prefix of "//depot/x/" (for the x
 branch). The benefit of this approach is that the Builders get sensible
 filenames to work with like foo.c instead of x/foo.c . The obvious
 disadvantage is that you have multiple buildmasters.

 2: use one master, and do the branch-filtering in isFileImportant. In this
 case, the ChangeSource should use a prefix of "//depot/", allowing the
 branch indication to remain in the "relative" filename. The isFileImportant
 method of the x-branch Builder should return False for any filename that
 doesn't start with "x/". This will allow the Builder to simulate the effect
 of only paying attention to one branch: really, it is accumulating Changes
 for *all* branches, but it's marking the non-branch-X ones as "unimportant",
 so they won't trigger a new build. They do get "included" in whatever build
 eventually happens, though, so the disadvantage of this hack is that the
 blamelist will include all the ignored changes, and any build steps which
 want to do something with filenames (like trial's only-test-changed-files
 feature) will get really confused.

(note that your ChangeSource might not be getting input filenames that start
with "//depot/" .. it depends upon how you're feeding it. I'm assuming that
you're using some kind of commit hook script that invokes something like
'buildbot sendchange', but in any case the filenames go through multiple
programs/functions and you just need to pay attention to how they are
transformed along this journey).


In the new Scheduler scheme, you will set up your ChangeSource to properly
decompose the depot's filename into a (branch, filename) tuple, by providing
a function which knows about your project's branch-naming policy. Then you'll
set up two Schedulers, one for each branch. The Schedulers will be able to
feed the same Builder, if you like, because the SourceStamp that is handed to
the Builder will include the branch name.

hope that helps,
 -Brian