Call for testing of colocated branch support in bzr.dev

[Jelmer Vernooij]

Hi Gustavo,

Am 19/01/12 19:39, schrieb Gustavo Niemeyer:
>> Support for colocated branches in bzr.dev has now progressed to a level
>> where it is actually usable. At the moment, colocated branch support still
>> requires the 'development-colo' format. This should be merged back into the
>> default ('2a') format for 2.5.0 so it would work out of the box with
>> existing branches.
> Woohay! Thanks for pushing it forward Jelmer.
Thanks for giving me the final nudge to finish this by asking about it 
last week. :-)
>> $ bzr rmbranch second-colo-branch
> What about inheriting the git equivalent spelling for such commands.
>  From cobzr help:
>
>    cobzr branch -d<name>
>
> 	Delete branch<name>. Note that right now this is equivalent to
> 	git branch -D. In the future, this will check if the branch was
> 	merged and prevent deletion otherwise. The -d name was used to
> 	avoid teaching people to ignore by default.
>
>    cobzr branch -m [<old name>]<new name>
>
> 	Move (rename) branch<old name>  to<new name>. If<old name>
> 	isn't provided, the current branch will be moved.

I've considered that as well, and I vaguely recall discussing something 
similar to this in the past and I'm still not sure. I guess it's a 
question of whether we want few commands with a lot of different options 
that can make the command do fundamentally different things, or lots of 
commands that do just one thing. Whatever we do, we should be consistent.

"bzr rmbranch" has been around for a while (at least 2.4 I think), so if 
we wanted to add -d option to 'bzr branch' we should probably make sure 
to deprecate and eventually remove rmbranch. On the other hand, we also 
have "bzr tag --delete". We should either have them both as options or 
both as commands, I think.

The advantage of having delete and move as options to "bzr branch" is 
that it's familiar for users who have already used git, and perhaps a 
bit more easily discoverable (though we could also make sure that "bzr 
help branch" mentions "bzr rmbranch"). The disadvantage is that it makes 
the "bzr branch" set of options larger, and harder to understand, 
especially as we add more branch-removal-specific options.



> There are also some other commands that might be nice to support:
>
>    cobzr init<name>
>
>          Create a new branch with<name>. Will not share any history with
>          other branches.
This should work once init is updated to support sibling branches.

>    cobzr branch<name>
>
>          Create a new branch with<name>  based on the current one, but
>          don't switch to it.
bzr branch . <name> will do this once bzr branch starts supporting 
sibling branches.

I'm not sure about supporting "bzr branch <name>" to create a new branch 
based on the current one. It would make the behaviour of bzr branch more 
confusing - usually the source is the first argument and the second 
argument is the optional target.

Imagine when:

"bzr branch file:,branch=foo" treats the first argument as the source

and

"bzr branch foo" treats the first argument as the target


>    cobzr branch<location>
>
>          Fetch branch from location and store it on a branch name based
>          on the location's suffix.
>
>    cobzr branch<origin>  <target>
>
>          Create a new branch<target>  based on branch<origin>. Either
>          option may be a branch name or an external branch location.
>          Note that the parameter ordering here differs from git's
>          because it'd conflict with the native bzr branch command.
These will work once "bzr branch" is updated to support sibling branches.

Cheers,

Jelmer