[PATCH] cascading lookup support in LocationConfig (bug 33430)

[James Henstridge]

On 19/09/06, Aaron Bentley <aaron.bentley at utoronto.ca> wrote:
> James Henstridge wrote:
> > The problem I see with this is that it affects all configuration data
> > inside the section.
>
> Yes, this is a problem I saw also.
>
> > I suppose another method would be to encode the policy into the
> > section name.  Maybe something like this?
> >
> >    [/some/branch]
> >    email = My email
> >
> >    [/some/branch#no-recurse]
> >    push_location = sftp://...
>
> I was also considering "[/some/branch/*]".    One problem is that
> bzr/branch.conf and ~/.bazaar/global.conf don't have sections.

Well, the policy for those two files are fairly well defined already,
aren't they?  I think we only need to worry about locations.conf at
this point.

> But another alternative would be to configure values individually.  I'm
> not sure what that would look like.  I guess it could be:
>
> [/some/branch]
> submit_location = sftp://..
> recursive_submit_location = True
> push_location = sftp://..
> recursive_push_location = True
>
> or
>
> [/some/branch]
> submit_location = sftp://..
> push_location = sftp://..
> # ConfigObj understands lists natively
> recursive = ["push_location", "submit_location"]
>
> > Something similar could be done for the "append remaining path
> > components to config value" policy you mentioned earlier in this
> > thread.  An alternative to the above syntax might be "?recurse=false"
> > -- both couldn't be confused with URI path components.
>
> Hmm.  It would mean that people couldn't use query strings in branch
> paths, but it would mean we could be more flexible in specifying policy
> there.

I just thought of an even simpler delimeter we could use here: a
space.  So it could be:

    [/some/branch only]
   push_location = sftp://...

(it's a little informal, but scans easily).


> >> If recurse=False were set for all automatic values, do you think
> >> ignore_parents would still be useful?
> >
> > It depends on whether anyone was relying on the current shadowing
> > behaviour or not.  Maybe it would be better to leave it out and see if
> > anyone asks for the feature.
>
> Okay.  So I apologise for turning your patch into a design discussion.
> Let's not let cascading block on config syntax discussion.  If you don't
> mind producing a version that retains the existing recurse
> functionality, I think I can approve that.  It's your choice whether to
> include ignore_parents.

Okay.  I'll put prepare a bundle for that.


> We can deal with syntax enhancement separately.

Okay.  I agree with the idea of putting the policy in the
set_user_option() routine and the config file is probably the best way
to go.  I also think storing the policy for a set of keys in the
section name will be the easiest for users to understand.


James.