[PATCH] cascading lookup support in LocationConfig (bug 33430)
james at jamesh.id.au
Thu Sep 14 08:52:54 BST 2006
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
# hack on the branch
bzr push sftp://...
rm -rf ~/work
Then a few days/weeks/months later:
bzr branch http://... ~/work/subdir
# hack on branch
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?
More information about the bazaar