[rfc] bzr-colo into core

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 3/22/2011 11:54 PM, Robert Collins wrote:
> 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
> 


Just to second what Rob is saying. I personally use a small handful of
trees. For most work I have a "trunk" tree split out from all my feature
branches. So something like

 /project/(.bzr/repository)
    trunk/(.bzr/checkout)
    branch-a
    branch-b
    branch-c
    work/(.bzr/checkout)

Feature branches are generally short lived, and not very diverged from
trunk. So switching between them is pretty painless.

In the case of bzr, I went one step further, because we have
longer-lived stable branches:

 /project/	# shared repository
   bzr.dev/ 	# checkout, bound to lp:bzr
   2.1/pqm	# no-tree branch bound to lp:bzr/2.1
   2.1/branch-a	# local feature branch, targeted to 2.1
   2.1/branch-b
   2.1/work/	# lightweight checkout, pointing at any 2.1 branch
   2.2/pqm	# no-tree branch bound to lp:bzr/2.2
   2.2/branch-a
   2.2/branch-b
   2.2/work	# checkout, pointing at any of the 2.2 branches
   2.3/...
   feature-x	# branch targeting trunk
   feature-y
   work/ 	# checkout, generally pointing at a feature branch

I do most of my work on trunk-related branches, which is why it is at
the top level. I then have a separate working tree based on each major
stable series. And I aggregate the branches that are targeted for those
releases.

So if I'm putting together a patch for 2.2, I'll:
  cd 2.2/work
  # make sure I'm on the pqm branch
  bzr up
  # Make sure I have the latest 2.2 branch content
  bzr switch --branch ../feature-name

Switching a tree from 'bzr.dev' to '2.1' can be rather slow, since they
have diverged a fair amount by now. However, switching within a given
series is always pretty fast.

Note that I also set up my shell to display what branch I'm currently
working on. It is actually a semi-hacky C program, because bzrlib
startup time is too much to load again for every command line prompt.
  lp:~jameinel/+junk/my_nick

Which gives me prompts like:

 jameinel at Falco ~/dev/bzr/work {lp/2.4-cheaper-iter-entries-by-dir}
 $

(Although also color coded)

I think my biggest concern for integrating colo branches is what happens
when you really do want to share a repository across multiple working trees.

I realize we haven't sorted out how the specific invocation would work,
but having "bzr give-me-that-stuff" end up giving you:

 project/ # repo
  branch/
  work/	  # checkout pointing at 'branch'

I think the main thing it lacks vs colo is the ability to have many
branches in a single "get-me-that-stuff" invocation. But it gives you a
ton of flexibility in how you want to end up working on your projects.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2JV4AACgkQJdeBCYSNAAOBTQCgk0tIXPCn15QsUetMAsFPL/Ok
xmEAnixKpbwPg2Dk5xgXivl5WFaRspeB
=vRH9
-----END PGP SIGNATURE-----