[rfc] bzr-colo into core

[Gordon Tyler]

On Mon, 21 Mar 2011 18:48:36 +1100, Martin Pool <mbp at canonical.com> wrote:
> {summary}
> 
> Let's make bzr-colo the default model for bzr 3.0 in September.

I would love to see this happen. I already use bzr-colo for a project at
work which uses a bound branch to a svn repo and it's great. Admittedly I
only use it for local feature branches, so I haven't tried to do any major
merging.

> People working on large trees really want to have just one on-disk
> checkout at a time, so they don't use too much disk space and so they
> don't waste time building a new tree just to start a new branch.  That
> case is supported at the moment through either setting up a branch and
> a tree-less repository, or through various plugins, but it's not
> completely natural.

It's also nice for people who use IDEs and don't version control the IDE
metadata that lives in the working directory.

> By "the main path" I mean this is the way that the documentation,
> help, and command defaults guide people to working.  Since bzr-colo is
> currently a plugin to do this we would have to either make sure the
> plugin is installed for everyone using bzr, or to merge it into bzr
> (perhaps updating some of the code on the way.)

I would highly recommend incorporating the *concept* and maybe the
underlying implementation should be brought into core but not the command
names themselves. I think "colo-*" commands would be out of place and weird
as a core feature. This means that stock bzr commands need to understand
colo branches, e.g. "bzr branch foobar" or similar should be the equivalent
of "bzr colo-branch foobar".

> bound branches - For instance being able to have a single branch
> that's synchronously updated by multiple people, such as a
> team-maintained trunk, is a strength of Bazaar, it seems to be
> appreciated by many people, and the implementation is pretty clean.
> We can easily keep this by letting branches within a colo be bound to
> a (probably remote) branch.

Agreed 100%. I use a bound branch in my bzr-colo workflow to great effect.
I have a bound branch of my project's svn trunk and then local non-bound
branches of the bzr trunk to add features or fix bugs. Once a local branch
is done, I merge it into the bzr trunk, which automatically commits to the
svn trunk. This means less disturbance and "weird" stuff when working with
other developers who just use svn on the same project.

> It seems like this could logically be supported within bzr-colo, but
> it may not be trivial.

I haven't had any issues with it so far. It Just Works.

> separate checkouts - Useful when you want to leave uncommitted work
> around, and the tree is relatively small enough that you don't mind
> having a few copies around.  (Easily created with bzr colo-checkout.)

Perhaps, but I have seen another suggestion for this which is
auto-shelving when switching.

> We'd need to think about how this would integrate with Launchpad,
> which at the moment deals only with single branches.  It may be
> reasonable to may each ~user/project container to being effectively a
> branch set.

That would be great.

Ciao,
Gordon