Multi-branch work (was Re: Equivalent to svn tags?)

Matthew D. Fuller fullermd at over-yonder.net
Thu Oct 25 13:09:46 BST 2007


On Thu, Oct 25, 2007 at 09:07:17PM +1000 I heard the voice of
Ian Clatworthy, and lo! it spake thus:
> 
> I think this needs more discussion. Here's a good start IMO:
> http://jelmer.vernstok.nl/blog/archives/192-Bazaar-Need-for-a-Product-object.html.

1 nameserver down, the other doesn't carry the zone   :(

I get itchy about having this sort of discussion.  There's ginormous
resistance to altering bzr's single-branch fixation (as there should
be), and even though multi-branch dealings or all-in-one setups can be
constructed that don't have to change that, it still tends to muddy
the waters of the discussion.  And, even when reasonably productive,
it tends to just fall into the gaping Pit Of Round Tuits; I've been
holding back a bit of SS-related rant lately for that same reason.


> Thinking out loud, I know the mantra
> 
>   "repositories are a storage optimisation only"
> 
> is deeply ingrained in our thinking. But I wonder whether having the
> option of tagging them as 'product repositories' would help

Well, I wouldn't necessarily want to conflate the "push/pull a block
of branches" with "share storage among branches".  In fact, having as
we do already that split with repos being non-semantic (which isn't
_entirely_ true, but it only breaks down in fairly edge cases, so it's
close enough) gives us an advantage in that it makes it much EASIER
for us to define a layer for blocks of branches.

Consider bzr; I'd want to branch/pull my local copy of "bzr", and I
get bzr.dev right now.  I want bzr.dev, but also bzr.0.91 and bzr.0.90
and bzr.0.12 and all the release branches; not because I have a use
for them NOW, but because that way they're already handy when I think
I might want one.  In checking the history of bugs reported, for
instance, I test with .dev and the last release (which I keep
installed system-wide).  If older releases were just a 'co' of their
release branch away, I'd test them too.  If I have to look up a revno,
or pull down a tarball, I'm not going to bother.  But we may want to
have other branches (long-lived dev branches, say) in that repo there
that we wouldn't want to bother grabbing for 'normal' cases.

Having a pseudo-branch to branch/pull, that would end up giving you a
set of branches (maybe in an all-in-one dir, maybe just
creating/updating them all in a normal repo), we can keep a nice
separation, which gives a lot more flexibility.  In fact, it occurs to
me that this could be considered a parallel issue with nested trees as
well; some mechanisms can probably be dual-purposed.

Conflating "in the repo" and "will be pushed/pulled together" can have
negative side effects; mtn does that, and it made working on a project
with it[0] unpleasant, since I had to keep a whole separate mirror
repo to create my branches in, or else all my temporary branches would
appear forever in the global mesh as soon as I sync'd[1].


I really love bzr working branch-at-a-time.  For a lot of workflows
(including those that most of my active work happens in), it works
great.  Often better than an all-in-one would, I dare say.  But there
are certainly situations where an all-in-one, or multi-branch
branch/push/pull (as mentioned, those two don't have to be the same
thing) (and doing them efficiently cross-refs SS stuff too) provide
decidedly superior capabilities.  I'm no authority, and I haven't
spent all that much brainpower on it, but I don't see any technical
reason why we can't have our cake and eat it too on this issue.




[0] That of course was before I updated my system to using gcc 4.2.x,
    at which point mtn stopped working completely.  Sure am glad I
    didn't choose to keep _my_ code in it...

[1] Well, there are some config params that, AIUI, would let you
    define patterns of branches to sync and branches to ignore.  But
    there wasn't any documentation of them, and life's too short to
    figure it out by experimentation.



-- 
Matthew Fuller     (MF4839)   |  fullermd at over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
           On the Internet, nobody can hear you scream.



More information about the bazaar mailing list