[RFC] Suggested directory names for branches
John Arbash Meinel
john at arbash-meinel.com
Thu Apr 12 14:29:34 BST 2007
Aaron Bentley wrote:
> Hi all,
> There's a bit of mismatch between Bazaar and launchpad, because
> launchpad encourages branch names to end in "/trunk" and Bazaar defaults
> to using the last component as the directory name.
> And further, some projects have urls that do not end with the desired
> directory name.
> Does it make sense for branches to provide a "suggested dirname"?
> For example,
> $ bzr branch http://bazaar.launchpad.net/~bzr/bzr-gtk/trunk
> would produce a directory named "gtk".
> This would work better with our current plugin development practices,
> which encourage people to install plugins by branching. On the other
> hand, it's more config data to worry about.
> Really, I'd rather fix launchpad than Bazaar, but realistically, I
> figure I have more chance of fixing Bazaar.
Well, it happens with anything with branch naming. If you have
"project/branches/foo" you are going to get 'foo' when you checkout.
Which when you are doing multi-branch development is actually reasonable.
I think the primary thing is that *plugins* should know what name they
are installed as. They aren't even happy with "gtk.ab" or even a
So I think plugins are a pretty special case, where when branching
someone else's code you want to end up with a special name locally.
(There is the other issue with LP that you have to write names with
dashes which won't ever work as plugin names, and that we have a
convention of 'bzr-foo' though when you install the plugin it should be
In the past, I thought having plugins contain a member in __init__.py
which said what the real path should be would work, but I understand
that won't update the standard python search rules, which allows plugins
to depend on eachother.
Currently the only real way to do it in __init__.py to do:
if __name__ != 'bzrlib.plugins.expected_name':
warning('This plugin is installed as %s'
' but should be installed as expected_name'
I certainly think that 'gtk' should do that, since it has a very direct
expectation of its name.
I think most of my plugins use relative names to avoid this.
I kind of like the idea of having 'branch.conf' have a 'suggested name'.
However, it seems like a fairly involved change just because of how our
If we consider it a hint, we wouldn't need to have a new branch format.
PS> One other remote possibility using 'bzr branch lp:///foo' which will
create it locally as foo. Though that doesn't work for "lp:foo" which
tries to create "lp:foo" (and can't because that is on the http
supermirror), and it also doesn't work with a naming convention of
More information about the bazaar