[rfc] bzr-colo into core

[Martin Pool]

On 24 March 2011 11:05, Aaron Bentley <aaron at aaronbentley.com> wrote:
> 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?

I haven't used bzr-colocated myself.  I understand from Jelmer that it
is pretty similar to bzr-colo but with a different bzrdir format
marker, meaning that people without the plugin installed cannot read
it at all.  imbw.

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

Right, but that would mean we could concentrate on making one primary
setup better.  At the moment there are stacking-related performance
and functional bugs that are good to fix, but that don't help most
non-Launchpad use of Bazaar, and vice versa.

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

Good point.  I couldn't see a bug for that so I filed <http://pad.lv/741515>.

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

Or even both.  I think it's an important thing to improve.

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

Right.  Knowledge of the moving parts should be there if you want it
but not necessary.

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

In some ways this is the best of both worlds, and the thing advanced
users tend to gravitate towards: multiple working trees, but not one
for every single branch; also the working trees separate from the
branches so they can easily be destroyed or switched.

It seems like in your case, but not for John, you always name the
checkouts after their branch, and therefore never switch them?

One snag here is that if you do ever switch your checkouts we lose the
nice property of implicitly knowing which branch you're addressing.
People address that by having some checkouts called eg 'trunk' that
they know they should never switch; and others called eg 'work' that
they do switch around.  Maybe that's fine.

-- 
Martin