[rfc] bzr-colo into core

[Martin Pool]

(I'll just reply to a lot of ideas across the whole thread; my
previous reply got a bit mangled somehow.)

Using one reusable tree is useful for some people, but clearly not the
best option for everyone.  It may not even correlate very much with
tree size, except that big trees do make the stakes higher.  I'd like
bzr to have good answers both for those who want many separate trees
and who want reusable trees; also for those who want synchronous
commits to central branches vs distributed.

We are going through a transition at the moment to SSDs where disks
have stepped down to be smaller though faster.  If you have an 80GB
laptop SSD, a fair amount of software installed, and you work on a 1GB
source tree, you may find disk space a constraint.  I do backups over
the network (at about 100kB/s) and having multiple working trees
touched per day slows things down noticeably.  Beyond just space,
reusing trees may mean fewer rebuilds (if you trust your build
system), less disk cache contention (therefore faster branching,
builds, etc).

Hardlinking trees would help with many of these.  I don't want to
force people to reuse trees but I do want to make it work well.

I think the kind of problems we should tackle are:

 * I think accidentally ending up with branches having their own
repositories rather than sharing one is a real trap, because things
will work but be slow.  I'd like to make sure this doesn't happen.

 * I'd like it to be easier to push/pull whole sets of branches at
once.  (Of course you should still keep the option to push or pull
just one.)  Eventually I'd like to have a daemon that just
automatically does all network transfers in the background.

 * Even if having one repository directory plus branches plus separate
working trees is the best way to go, neither the UI nor the
documentation really naturally lead you to set this up.  John has a
setup that clearly works well for him but it's not easy for someone to
reproduce it.

 * I feel the user model is in an unhappy valley where users do need
to know about the repository, branch, wt components, but the ui and
documentation don't really expose them as such; instead we tend to
talk about the stylized arrangements such as lightweight checkouts and
standalone branches.

 * The thing that is closest to being a default, standalone branches,
is not something we would normally recommend at all.

 * The stylized models we do present don't really flow from each
other, but rather you have to go back and set things up again if you
want to switch from say using standalone branches to using a
repository with branches and a switchable tree.

There are other ways to address these than bzr-colo.  We could for
instance standardize John's model; or we could make the moving parts
very clear and just describe how to compose them.

Martin