Some feedback on colo plugin

[Alexander Belchenko]

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

Well, proper use of mainline paradigm forces me to use feature branches. And for long lived projects 
they are very useful, IMO.


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

Oh, I did not knew you're planning to support 2.0. Your test suite perhaps completely non-2.0 
friendly because shell-style tests is the 2.1 new feature IIRC. So I've supposed you're target 2.1 only.

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

I agree. Just old habits to use switch -b.

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

Well, I think the consistency with bzr (instead of git/hg) is more important here. Also hg has no 
idea of light checkouts. Not sure about git.

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

I can explain. We have lp:qbzr/0.18 branch where 2 stable releases (0.18 and 0.18.1) live, and 
development still continue. So when I need to build installer I need the working copy of exactly 
specified version (e.g. -r tag:release-0.18.1) instead of tip of 0.18 branch. I don't like the idea 
that I should create new colo:branch for every tag/release. Also when I build release there is 
created tarball, compiled mo files, installer and gpg-signatures. When I no more need the release 
tree I'm usually do `bzr remove-tree` but keep tarballs/installers for some time on my disk.

So, if bzr can support light checkout not from tip, but from any revision, that would be sufficient 
for me. I think it's somewhat related to `update -r` patch. I'm not sure about the status of that patch.

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

Hmmm. I don't know why but using
$ bzr branch lp:~bialix/bzr-colo/checkout colo:bialix-checkout
was not very obvious. I dunno why.

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

I'd rather extend --from-branch instead of adding new --from-xxx because:

1) Today you can use just --from as short form of --from-branch and it will work thanks to python 
option parser library. I'm often use shorter names for options because I'm lazy to type something long.
2) There is already DWIM implementation for `bzr switch` command, which accept relative paths and 
full URLs as well. So checking argument of --from-branch to be full URL (lp:xxx can be expanded to 
full URL by request) is possible.

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

That's easy: I'm working on my working computer, have some unfinished work in couple of feature 
branches, and I want to get this to home (or just to another computer). So I'd expect to simply run 
one command (colo-push?) instead of puzzling which branches I need to push and which ones I don't.

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

Thanks,
Alexander