jml at mumak.net
Tue Jul 7 09:06:31 BST 2009
On Sun, Jul 5, 2009 at 1:33 AM, Aaron Bentley<aaron at aaronbentley.com> wrote:
> Jonathan Lange wrote:
>> To make everything work nicely, we ended up manually editing
>> locations.conf to look an awful lot like this:
>> submit_branch = /home/jml/src/bzr/bzr.dev
>> public_branch = lp:~jml/bzr
>> public_branch:policy = appendpath
>> push_location = lp:~jml/bzr
>> push_location:policy = appendpath
>> submit_to = bazaar at lists.canonical.com
>> public_branch = lp:bzr
> I assume you mean [/home/jml/src/bzr/bzr.dev]
I have a symlink from there to 'trunk' to take advantage of muscle
memory developed on other projects.
>> Is there something we could have done that would have been simpler
>> than that? If not, what can we do to make it simpler?
> I don't think it's strictly necessary to provide submit_branch, as this
> will fall back to parent, which will be /home/jml/src/bzr/bzr.dev anyway.
Didn't know that, thanks.
> We could make public_branch the default push location. For cases where
> the public_location is not writeable, you could still specify
> push_location for the writeable location.
Good idea. This seems like something that could be done now with not
> The bzrtools create-mirror command will automatically set the
> public_branch value. I'll make it copy the child_submit_to value as
> well, but for this to work, it needs to be set on
I didn't know about create-mirror.
ISTR James Westby filing a bug on Launchpad about setting this value...
> So we can easily eliminate setting the "submit_to" value using
> create-mirror. The public_branch is more problematic because the your
> "public_branch = lp:~jml/bzr" value in locations.conf will override the
> value set in .bzr/branch/branch.conf by create-mirror.
Why would this be a problem?
> We've deliberately given precedence to locations.conf because the user
> may have no control over branch.conf, but perhaps we should consider
> making locations.conf only override the branch.conf value if configured
> to do so, with public_branch:policy=override or something similar.
I don't know how to guess the impact of a change like that. It sounds impacty.
> In a similar vein, there are ways we could make it easier to specify the
> appendpath policy
> - make it the default
> - make it the default, only for values that indicate locations
> - specify policies with metacharacters, such as + for appendpath
> - allow substitution of values:
I like making it the default. I doubt it would surprise many newcomers
or break any existing configs.
And again, it's something we could reasonably do before 3.0.
> So by changing the behaviour of create-mirror and the config mechanism,
> we could get it down to:
> public_branch+ = lp:~jml/bzr
> The following config values will have been set by create-mirror:
> public_branch = http://bazaar-vcs.org/bzr/bzr.dev
> child_submit_to = bazaar at lists.canonical.com
> What do you think of that?
That would be very nice.
> Of course, it would be easier to provide a plugin that just set up good
> defaults for working with a project. I understand you've already
> travelled down that road, so I assume that kind of solution doesn't appeal.
It's more that I've hit my own limit on code that I can maintain
against a moving API.
More information about the bazaar