[rfc] bzr-colo into core

[Robert Collins]

On Wed, Mar 23, 2011 at 8:12 AM, Eli Zaretskii <eliz at gnu.org> wrote:
> OTOH, the use cases where one would _not_ want colocated branches are:
>
>  . branches that diverged significantly
>
>  . branches that are configured in different ways (e.g., with/without
>   some optional library)
>
>  . branches that are built for different target systems

This is just some data on my experience here. I work on two fairly
different projects (amongst many ;)) that are both decent sized trees
and have long compile times.

One is Launchpad - the schema build time there is several minutes, but
the build affects global state (a postgresql DB with a fixed name). So
there isn't much (any) point avoiding rebuilds; I use a single working
dir and bzr switch. Most of the time I don't need to rebuild my
schema, so I can switch branches in subsecond time, and be pretty
productive.

The other project I want to mention is squid. Its history is pretty
modest - 80 odd MB, and it only has 2K files, 31MB of source. However
its c++, has a relatively long build time, and has a combinatorial
explosion of interacting options. (e.g. support for interception on 3
backends, iCAP, ESI, store IO modules, disk IO modules, LRU vs HEAP
cache mangement policies, QOS etc etc). What I do here is to have
multiple working trees, and multiple out-of-tree (VPATH) build trees;
then I can build 3 or 4 configs spanning the key interactions at once.
I do have a common working tree for small things (with its own 3-4
build configs) - I'll switch small patches in there, and only use
dedicated trees for big works. (Not that I have a lot of squid hacking
time these days, but thats a different story).

-Rob