locations.conf ideas?

[Jonathan Lange]

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:
>>
>> [/home/jml/src/bzr]
>> 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
>>
>> [/home/jml/src/bzr/trunk]
>> 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
much effort.

> 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
> http://bazaar-vcs.org/bzr/bzr.dev.
>

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
>   "public_branch+=lp:~jml/bzr"
>  - allow substitution of values:
>   "public_branch=lp:~jml/bzr/$PATH"
>

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:
>
> [/home/jml/src/bzr]
> 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.

jml