Some feedback on colo plugin

[Neil Martinsen-Burrell]

On 2010-02-06 08:58 , Alexander Belchenko wrote:
> I'm using your colo plugin with big pleasure for the last couple of 
> months (since the day you're announced it). I'd like to say "big
> thank you" for your good work.
> 
> I have some feedback for you based on my usage experience and my 
> preferred workflow. I'm using colo for doing development on bzr
> plugins (before I've also used light checkouts for them, but
> repositories was outside my plugins directory) and for short-lived
> feature branches in my regular work (not bzr-related).

You are most welcome.  I've been using it for all of my Bazaar
development now as well.  (I rarely use feature branches in my regular
work.)

> 1) This plugin mostly works with bzr 2.0. The colo-init command does
> not work because it uses 2.1 API, but as workaround I'm using the
> sequence:
> 
> bzr init 
> bzr colo-ify

Since I've been running it on bzr.dev, I haven't noticed when I've used
an older API.  I will try to run the selftest under the 2.0 branch to
track these down.  Feel free to file bugs against these, since I intend
for it work on 2.0.  (As an aside, I imagine that colo-ify could become
a sub-option to reconfigure once colocated branches are supported in
Bazaar core or there is a reconfigure registry for use by plugins.)

> 2) I don't use native colo-branch command, instead I'm using `switch 
> -b`, because it looks simpler to remember and to use. But I think 
> `colo-branch` could be useful as well because of the option 
> --from-branch. Just don't have real use case for it.

I use --from-branch a lot because I usually have only one working copy
which usually is pointing to a feature branch that I'm working on and
when I want to merge someone else's work, then I don't have to switch
back to trunk and then switch -b to start the new branch.

> 3) The most useful command for me is `colo-branches`. I've added
> alias for it as `clist` because the original name is too long. I'd
> like to suggest you provide some similar alias in the plugin itself.

I will look into adding an alias.  Originally, I wanted to keep all of
the plugin's commands in the colo-* "namespace", but if the plugin
becomes more generally useful, I would consider adding aliases.  In
development right now is a graphical equivalent to colo-branches called
qbranches (plus Bazaar Explorer integration [thanks, Ian!]).

> 4) `colo-prune` is useful. The name is hard for me because I'm not 
> native English-man. Maybe alias of `colo-delete` would help. I've not
> used yet --clean or colo-clean.

I think that colo-delete is certainly reasonable.  I will add it as an
alias.  Look at the latest trunk for a GUI version called qprune (now to
be aliased as qdelete).  For ordinary feature branch development, I
don't anticipate that --clean or colo-clean will be much used.

> 5) I think the name of colo-clone is wrong, and this command should
> be renamed to colo-checkout. The merge proposal: 
> https://code.launchpad.net/~bialix/bzr-colo/checkout/+merge/18760

I've merged your proposal, but to explain, I got the name from Stephen
Turnbull's message that said that one of the things he liked most about
git was the ability to do "git clone --other-options-I-cant-remember" to
get another working tree.  So, I borrowed the name, neglecting its more
common use in git and hg, etc.  colo-checkout it is.

> 6) I'm using colo for my work on qbzr plugin, and I have 3 long
> lived branches in there: trunk, 0.18 and 0.14 (each for corresponding
> stable series). I found using colo for release branches not very
> handy when I need to create new release and build tarball/installers.
> But colo-checkout is not very useful for me too, because I prefer to
> get new copy of the release branch somewhere, instead of new
> checkout. Also I'd like to use colo-checkout more like standard
> checkout, i.e. running it in the directory where I want to have new
> checkout and point to colo workspace, instead of running it from colo
> workspace and point to destination. Just my habits.

Can you explain more about why you like to get a fresh copy of the
release branch?  I track bzr.dev and bzr-2.0 using colo-checkout and
because of the effect of bzr pull in a lightweight checkout, I only have
to do "cd ~/src/bzr/bzr.dev; bzr pull" to update that branch within the
colocated workspace.  As far as being able to use checkout from the
destination directory, Bazaar's "checkout --lightweight" can be used
with the long form of the colo: specifier to checkout a branch directly:

$ bzr colo-init test
$ bzr checkout --lightweight colo:test:trunk new_checkout
$ cd new_checkout
$ bzr colo-branches
* trunk

> 7) Working with merge proposals for qbzr I'm often need to get the
> copy of proposed branch into my colo workspace, but there is nothing
> in colo plugin to support this. Today I have to do something like
> this:
> 
> bzr switch -b new-branch bzr pull --overwrite lp:user/merge/proposal
> 
> How about adding colo-get command for this, or to extend colo-branch 
> command to get the branch for external location? I'll be happy to
> work on such patch once we'll agree on the design of this feature.

Bazaar's standard branch command works with targets specified with colo:
 Thus

$ cd bzr-colo
$ bzr branch lp:~bialix/bzr-colo/checkout colo:bialix-checkout
$ bzr switch colo:bialix-checkout
$ bzr colo-branches
...
* bialix-checkout
...

If we wanted to make the two steps into one command, I think that adding
a --from-remote option to colo-branch is completely reasonable.  The
issue with --from-branch is that it is meant to be used with branch
names and so it interprets "bzr colo-branch
--from-branch=lp:~user/merge/proposal user-merge" to mean creating and
switching to a new branch starting from
.bzr/branches/lp:~user/merge/proposal.

> 8) I've not used yet colo-fetch, can't say much.
> 
> 9) colo-fixup is brilliant.
> 
> 10) Ability to push/pull entire set of colo branches? I have some 
> experience of working with multiple branches in scmproj, also I've
> used repo-push plugin some time. I would like to have such
> functionality but we need to agree on the design.
> 
> Based on my repo-push experience there is problem when you have
> deleted some branch in your local copy, but this deletion won't
> propagate to destination side. I think colo-push/colo-pull should be
> aware of this and at least provide --delete flag or something similar
> to ensure deletions are propagated.

We should think more about the specific uses of passing around an entire
"bundle" of branches.  Originally, I intended bzr-colo to just simplify
the local problem of working with many branches and figured that
push/pull could be used simply by switching to a single branch and then
pushing or pulling it as necessary.  What situations would you expect
people to want to manage entire colocated workspaces in?

> Another question: can I have tree-less colo workspace? From the fact 
> it's light checkout with shared repo inside the answer is not. But
> for synchronizing workspaces via internet or USB stick we need to
> support configuration where no working tree required. Any ideas how
> to achieve this?
>
> Maybe core devs can shed some light on this problem?

I think that this needs deeper support in Bazaar similar to Jelmer's
proposed colocated branch collection format.  Currently, a tree-less
colocated workspace is just a directory with a shared repository hidden
under .bzr/branches.  The multi-pull command could conceivably be used
to synchronize from this, but it would mean working directly inside
.bzr/branches (which is what bzr-colo means to avoid).

Apparently, a more official branch collection format was talked about at
the sprint, but I'm not sure what will happen now.

> What if I colo-push workspace to LP? Will it break everything
> horribly? Maybe we should explicitly prohibit colo-push to LP?
>
> I saw there is loom branches supported on LP. How it actually works
> on LP?

It's pipeline support that exists on LP.  Perhaps Aaron could talk more
about how bzr-pipeline communicates with LP, since it too is dealing
with a collection of branches stored in a hidden location.

-Neil