[rfc] bzr-colo into core

[Aaron Bentley]

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

I'm in favour of colocated branch support in bzr.

I haven't seen any discussion of bzr-colo vs bzr-colocated.  I
understood that bzr-colocated was designed more for tight integration
with bzr, where bzr-colo was designed to be usable today.  Is it worth
considering integrating bzr-colocated instead?

You suggested that Launchpad might treat branches under a single
~username/project as colocated.  What would the advantage of that be?
ISTM that there is no common case where retrieving all 279 of my
launchpad branches would make sense, and they are already grouped by
project anyhow.

Frankly, I have no idea how Launchpad should model this.  I might be
interested in all the branches in a pipeline.  Or maybe to get a branch
and all its prerequisite branches.  Or maybe to get all the branches
currently pending review.

AIUI, colocated branches means shared repositories.  And Launchpad means
stacking.  If we combine them as-is, we'd better be prepared to spend
some effort making stacked shared repositories work nicely.

On 03/22/2011 10:18 PM, Martin Pool wrote:
> 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.

Even this is temporary.  I have a 256 GB SSD, which is comparable to the
size of my previous laptop's hard disk.

> 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.

There's rudimentary support for hard-linking in branch, checkout and
bzrtools' link-tree, but the stat cache tracks ctime, which means that
creating hard links invalidates the cache entries.  This is a sizeable
wart in our hard-link support.

>  * 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.)

Especially if you colocate all branches in lp:~/user/project !

>  * 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 like using lightweight checkouts and separate branches too.  But it's
too complicated to set up, so pipeline's reconfigure-pipeline command
sets up pseudo colocated branches.  This unfortunately doesn't play well
with the appendpath config policy, so I've proposed a new one:
https://code.launchpad.net/~abentley/bzr/appenddir

The take-home for me is that separate-trees setup should be much easier,
or colocation should be supported better.

>  * 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.

I think we should work toward a default experience that's so lovable
that most people use it, and don't have to think about repositories and
working trees as individual components.  That should be for advanced users.

> 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.

I'm not clear how close John's model is to mine.  I have a directory
with lightweight checkouts for all active branches.  Inside that, I also
have a directory named "branches" which is a shared repository.  Inside
the "branches" directory are all my branches.

So:
launchpad
launchpad/branches <- Shared repository
launchpad/branches/foo <- repository branch
launchpad/foo <- Lightweight checkout of /launchpad/branches/foo

I really love the clean separation between branches and working trees.
It means that the branches are out-of-sight, out-of-mind, but I still
have them if I need them.  And my lightweight checkouts are a kind of
to-do list.

I feel like I've been swimming against the current for years.  I'd love
to have something like my workflow standardised.

I wish colocated branches didn't mean single working trees.  I find it
useful to have multiple trees of the same project at once.  I keep
copies of launchpad's stable, devel, db-stable and db-devel, not only as
branches but as lightweight checkouts.

That said, I could probably adapt.  Especially if it was easy to refer
to branches, and if pipelines-style shelve-and-switch switching were
supported.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2KitIACgkQ0F+nu1YWqI2U9wCfXIq9aXrXBczvaQpQhvSt3fS6
CJ8Ani2xZIIMdDxnQWGq+SsdlxOfLx/o
=2tuQ
-----END PGP SIGNATURE-----