A few thoughts on foreign integration...

John Szakmeister john at szakmeister.net
Mon Oct 18 16:46:55 BST 2010


So, as most of you already know, I've been using Bazaar to help do
distributed Subversion development.  It's definitely got its kinks,
but has been working fairly well.  There is one issue I'd like to find
a way to address, either by having our team work differently (but ont
connected, that's impossible), or by adding a feature to Bazaar.

The problem is that we need to have a long-term development branch.
We'll integrate other branches over time, and the other side will use
native SVN to do the same.  The problem comes in where some of our
changes get merged into another branch (says trunk).  Any file that we
created is given a new file id by bzr-svn.  So when we attempt to
merge their branch later, bzr goes conflict crazy (on a smaller
project, I'm getting ~100-150 conflicts).  Most of them are tree
conflicts because the file we introduced have new file ids.  Actually
content that has changed between us and trunk is actually very little.

So, thinking about this more.  I'd like a way to say "merge that
branch into mine, and just use the file ids of the other branch but
merge the contents".  I actually have a script that I've been writing
to help me do this, and it works okay (at least for certains kinds of
conflicts).  It introduces another problem though.  While I won't get
any more troubles merging the other folk's branch, we will have
trouble internally.  Everyone who has their own branch will have to
resolve this tree conflict mess.  Nasty.  So here's a thought: what if
there was a way to tell Bazaar that a file or directory has changed
ids.  The idea behind this is to say these two files, with their
separate history are now one with the combined history of both.  This
combined with an option in merge to help trigger path-based merging
instead of id-based merging would be nice as well.  I'm sure there are
many edges in there that I'm not seeing though.

I realize there might be other ways to solve this problem too, perhaps
using looms or pipelines.  Unfortunately, my experience with looms has
been terrible.  I spent several days trying to do what I thought were
simple things only to be met by screenfuls of tracebacks.  I imagine
it's probably better now, although it doesn't look like it receives
much active development.  I have used pipelines, but I don't believe I
can share those with a team (and I might not be able to do that with
looms either... it's rather unclear to me how the two tools fit with a
team of people who need to share a common branch).

Any ideas?  FWIW, I did take a look at Mercurial for this purpose, and
I have to say, it did pretty swell with one big exception: the
hg-to-subversion solution doesn't support long-term development
branches.  You have to use a rebase workflow, and you can have merges.
:-(  git-svn has similar issues too.  For long-term development
branches, in a distributed manner, bzr-svn is the only game in town
(well, you could say svk too, but I've had issues with that as
well--and it's pretty much dead).

Thanks!

-John



More information about the bazaar mailing list