Call for testing of colocated branch support in bzr.dev

[Gustavo Niemeyer]

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

Agreed, but there's another point to consider here: there's a well
establish software with a command set that people are used to. It's a
win to have a matching interface when there's no good reason to
disagree.

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

Understood. I had no idea the command existed beforehand. rmbranch
seems to do something unlike what the co-located version does, though.
I'd still suggest matching the interface given that there's choice
(there's no branch -d yet).

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

Agreed on both counts..

> bzr branch . <name> will do this once bzr branch starts supporting sibling
> branches.

Super.

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

Agreed.. I also felt a little bit dirty when implementing it in cobzr.
It makes more sense with git because the parameters are inverted (the
origin is the second one).

> These will work once "bzr branch" is updated to support sibling branches.

Uh.. exciting. :)

-- 
Gustavo Niemeyer
http://niemeyer.net
http://niemeyer.net/plus
http://niemeyer.net/twitter
http://niemeyer.net/blog

-- I'm not absolutely sure of anything.