[rfc] bzr-colo into core

[Aaron Bentley]

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

On 11-03-24 04:37 AM, Martin Pool wrote:
>> 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.

I think that there may be a conflict between shared repositories and
colocation.  For shared repositories, we want to group every branch for
a project.  Are users going to want to colocate every branch for a
project?  When working with pipelines, I want to group just the branches
in the pipeline.  I don't know how other users operate.

I have 48 branches of Launchpad at the moment, and I don't understand
how the UI story would work if they were colocated.  Would "bzr
colo-branches" list all of them?  I don't care about most of them, as
they've been merged, but I wouldn't want to have to delete them in order
to clean up the UI.  I'd rather have a way to list just the active
branches.  Would that mean just colocating the active branches, and
keeping the merged branches in a separate colocated location?

It may turn out that colocation and repository sharing are orthagonal.
If they are orthagonal, Launchpad doesn't have to start using shared
repositories, which could make implementation simpler.  I guess it's
even possible to use stacking for colocated branches, instead of shared
repositories.

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

I only switch when I'm using them for pipelines.  It goes something like
this:

# create branch "branches/cool-feature" and create a lightweight
# checkout "cool-feature"
$ bzr cbranch stable cool-feature
$ cd cool-feature
# Hack, then decide to break the work into two pieces
$ bzr add-pipe cool-feature-part-2
# Hack on both pipes, using "switch-pipe" to switch between 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.

Yes, it is a bit irritating.  Sometimes the checkout name gets pretty
far from the current branch name.  Currently, my branch name is
"json-init", but my checkout name is "export-translation-api" for
historical reasons.

> People address that by having some checkouts called eg 'trunk' that
> they know they should never switch;

Yes.  "stable" in my example above.

> and others called eg 'work' that
> they do switch around.  Maybe that's fine.

Yes.  One question for me is: could I be happy without my "stable"
checkout?  Mostly I use it for merge and pull operations, and I could
just use a branch for that.

Sometimes I want to test whether a bug is present in "stable" or see
what "stable"'s version of a file looks like.  Switch-pipe makes it less
painful to switch for these use cases, because uncommitted changes are
automatically shelved, instead of being merged into the switch target.

So where I'm at is
1. colocated branches are good.
2. colocated branches sharing a repository may not be good.  Perhaps it
   should be per-user.
3. colocated branches having a single working tree is probably not good.

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

iEYEARECAAYFAk2LYUcACgkQ0F+nu1YWqI3togCfVOWLPtbHargR1bLz4Yg8mUJC
FB4An0ff1w3eayFkRXfdJ6f39vAEGhe7
=7ufE
-----END PGP SIGNATURE-----