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

[James Henstridge]

On 11/09/06, Aaron Bentley <aaron.bentley at utoronto.ca> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> James Henstridge wrote:
> > On 08/09/06, Aaron Bentley <aaron.bentley at utoronto.ca> wrote:
>
> >> exact?
>
> > "exact" seems to be more appropriate for the existing "recurse=False"
> > mode (which I've preserved).  I'll try to explain what I mean with an
> > example.
>
> Ah, see I thought you were talking about a flag for get_user_value
> methods, not for sections.
>
> So get_user_value('push_location', exact=True) would not match recursive
> sections.  (or at least, not unless they were exact matches.)
>
> For what you meant, maybe ignore_parents?

That sounds good.

As I said later on, I am not sure the existing "recurse=False"
handling would be that useful if that policy is moved to how the keys
are accessed (is anyone using the feature?).

>
> > LocationConfig seemed the most appropriate place given how the
> > existing code worked, but I guess we can change that.
> >
> >
> >> If I query for "/home/abentley/bzr/nested-trees", I'd like to get back
> >> ("sftp://panoramicfeedback.com/var/www/opensource/bzr",
> >> "/nested-trees").  That would let me produce the url
> >> "sftp://panoramicfeedback.com/var/www/opensource/bzr/nested-trees",
> >> which I think is a much better result.
> >
> >
> > I wonder if this indicates that the decision on whether to cascade
> > should be decided on a key-by-key basis?
>
> It's possible.
>
> > The "push" config key definitely shouldn't cascade (unless it can
> > adjust the path like you've sketched out here), so the current
> > behaviour is a potential source of bugs.
>
> Well, that doesn't seem to be true of the submit location, so I wonder
> if it's true for the push location.  Might you have multiple branches,
> all with the same push target?

The case I was thinking of was something like this:
    bzr branch http://... ~/work
    cd ~/work
    # hack on the branch
    bzr push sftp://...
    cd ~
    rm -rf ~/work

Then a few days/weeks/months later:
    bzr branch http://... ~/work/subdir
    cd ~/work/subdir
    # hack on branch
    bzr push

Here a push location was recorded for a previous unrelated branch that
will affect a the new branch.  So I'd expect the push location to
either (a) not inherit from ~/work's config or (b) use ~/work's config
but modify the URL based on the subdir I'm in (what you suggested).


> > Other keys we'd pretty much always want to cascade, such as "email".
> >
> > Would it make sense to expose the two behaviours to the rest of the
> > code, or provide a way to register the policy for particular key
> > names.  What do you think?
>
> I think BranchConfig should set policy about whether particular values
> cascade.  LocationConfig can provide an API for specifying what you
> want, or provide enough information to determine whether the match was
> exact, as I discussed.

Then we'd need some way for other code to register what policy is
desired for particular keys.  I wouldn't expect BranchConfig to know
what the policy for the pqm-submit plugin's "pqm_branch" config key
should be, for instance.

>
> Can I ask what you think about the order of matching I've suggested?
> (i.e. exact LocationConfig, TreeConfig, recursive LocationConfig,
> GlobalConfig?)  I'm not really satisfied with it.  Although it seems
> correct, in a certain sense, it also seems confusing.

I'm not sure I can answer that.  I've never really used the
.bzr/branch.conf file directly at all.  Are there many options that
you'd want to have in both files?  Maybe this is another case where
the policy should be set on a key by key basis?


James.