Some feedback on colo plugin

[Alexander Belchenko]

Hi Neil,

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

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

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.

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.

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.

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

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.

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.

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.

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?

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?

Thanks,
Alexander