[rfc] bzr-colo into core

[Stephen J. Turnbull]

Eli Zaretskii writes:
 > > Date: Tue, 22 Mar 2011 07:14:05 +0100
 > > From: Nicholas Allen <nick.allen at onlinehome.de>
 > > Cc: Bazaar <bazaar at lists.canonical.com>
 > > 
 > > > 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.  
 > > I diagree completely. If you have a large tree or use a compiled
 > > language like C++ colocated branches are almost definitely what you
 > > don't want. You need multiple working trees so that you don't have to
 > > rebuild each time you switch a branch. If there's only one tree then
 > > when you switch the whole project will likely have to be recompiled
 > > again (especially if a common header file is modified because of the
 > > switch). This would be unacceptable for me.
 > 
 > I obviously agree, since I wrote that in almost these very words just
 > yesterday.

Erm, getting additional workspaces is trivial, as even git[1] users know.
Just clone the repo again.  Every git user does this, even for small
projects.  What's the big deal?  For Bazaar, it's not like the ability
to operate on remote repos (diff, missing, etc) will go away or even
become more difficult to use; it's just that the default mode will
make smallish or temporary branches much easier to work with than
before, especially in large trees.

Of course you *should* watch the UI proposals (if any) to make sure
that they *don't* make remote branches *harder* to work with.  But
given the inertia that this project has with respect to existing UI, I
think it's unlikely that that will happen.



Footnotes: 
[1]  The point being that in git, there are no non-colocated branches;
you must fetch all relevant commit data into the local object database
before doing any work with branches.