[rfc] bzr-colo into core

[Neil Martinsen-Burrell]

[I'm going to respond holistically to the thread since I missed it
happening. (My wife had a new baby on Monday.)]

First, let me say that this sort of attention to the user experience
of colocated branches is precisely what I hoped to achieve when
writing bzr-colo.  Jelmer's bzr-colocated already existed and Matthew
Fuller's Fascis article gave a conceptual ground to what I wanted, but
I wanted something I could actually use, thus the subtitle "Colocated
branches in Bazaar using present technology".  The reason that it is a
plugin and all of its commands are isolated by the colo- prefix is
because I wanted people to discover the ways that colocated workspaces
ought to work without being attached to the legacy of Bazaar's other
commands.

I think that it is clear from 15 months of use for myself and others
(and a gazillion people's experiences with git and mercurial) that the
model of a directory that contains a working tree, a store of
revisions and a way to access particular head revisions by name (this
is all that a branch is as Stephen Turnbull has pointed out here many
times) is conceptually simple for new users, effective for
collaboration and makes many of the common workflows very easy.  I
wholeheartedly support this becoming the default setup for Bazaar
(i.e. created by bzr init and others).

I don't however support the bzr-colo plugin moving into Bazaar core.
It was always intended to be a stopgap measure for UI experimentation
until colocated workspace support appeared in Bazaar.  I have a branch
in progress to make bzr-colo work with Jelmer's new metadata format
when it is present.  This is clearly the way forward, to rely on
Bazaar's existing commands and infrastructure when working with the
new object colloquially known as a colo-thing.  If we do the job
right, no command prefixed colo- should ever need to appear in Bazaar
core.

I also think that a major release like 3.0 is the right time to make a
change like this.  I am not wise enough to know if we need a format
bump or not, but I think this is a change that needs plenty of time to
bake in bzr.dev and maybe even a release or two before we consider
making it the default.

Some other less organized thoughts:

- Multiple working trees are key for large projects living in
colocated workspaces.  I have one bzr.all colocated workspace and
parallel checkouts that point back to that workspace for bzr.dev and
2.0, 2.1, 2.2 and 2.3 release branches.  This means I can easily test
my plugin against those versions with "cd ../bzr-2.1; ./bzr selftest
-s bp.colo"

- The importance of multiple working trees suggests the value of a
repository reference.  One of the biggest problems right now with
additional working trees created by "bzr colo-checkout" is that they
only refer implicitly to their colocated workspace (as the place where
their associated branch resides).  Explicitness about this seems
valuable.

- Bazaar shouldn't lose any capabilities from making this particular
configuration work well.  The great strength of Bazaar in this respect
is that it clearly distinguishes the three essential pieces of version
control: a revision store, a working tree and references to head
revisions (a branch).  A colocated workspace is simply a
reconfiguration of these three things.  Those who wish to use other
configurations should be able to easily do so.  (Personally, I think
that being explicit about these three things at the UI level would be
an improvement, but I have no specific proposals.)

-Neil