[Buildbot-devel] Re: Branches in changes

Brian Warner warner-buildbot at lothar.com
Fri Nov 25 22:37:00 UTC 2005


> 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.

Yeah. If I remember rightly, it goes like this:

 CVS: repository knows about branches, but it's a component of a
      multi-dimensional per-file version number rather than expressed in the
      file's pathname
 SVN: repository doesn't know about branches. branch policy is expressed
      through file pathnames, so all version numbers are scalars and
      repository-wide.
 Arch/Bazaar: repository knows about branches. branch name is really the
              archive-branch-version triple, and is orthogonal to both file
              pathname and version number. Version numbers are scalar and
              scoped to just the branch.
 Darcs: each branch gets a separate repository
 Monotone: gah, I forget, but I think it's roughly a property of the
           "version number". It's certainly not a property of the pathname.
 Perforce: Like SVN: branch policy is expressed through the repository-side
           pathname. Repository doesn't know about branches.


So we need some sort of repository-centric filename-to-branchname tool for
SVN and Perforce, and some above-the-repository tool for Darcs (actually I
have no idea how to get change notifications out of Darcs, so really it's an
unexplored issue so far).

> 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), ...)

Well, I'm really keen on sticking to the "one Change / one branch" approach.
That makes the rest of the Buildbot work-flow much much more sensible. Each
build is of exactly one branch, you can assign blame based upon branch
(everyone gets blamed for breaking TRUNK, nobody gets blamed for breaking
personal branches, etc), you can allocate build resources on a per-branch
basis (do the big tests on TRUNK but only some smaller tests on personal
branches, etc).

It does mean that perhaps tools like svn_buildbot.py should be allowed to
send multiple Changes when faced with files that don't all end up inside the
same branch.

thanks,
 -Brian




More information about the devel mailing list