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

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

James Henstridge wrote:
> 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).

I think a) would be the best choice, and best served by using recurse=n
in per-branch settings.  But it's really unfortunate to have the
settings for ~/work hang around after the branch has been deleted.
Because you can always create a new ~/work, and it will get the old
settings.  This is one of the things that makes ./bzr/branch.conf nice.

>> I think BranchConfig should set policy about whether particular values
>> cascade.
> 
> Then we'd need some way for other code to register what policy is
> desired for particular keys.

Let me stop here and say I don't mean "particular keys" per se.  I mean
particular configuration values.

So, for example, the policy for the user_id is set like this:

    def _get_user_id(self):
        """Return the full user id for the branch.

        e.g. "John Hacker <jhacker at foo.org>"
        This is looked up in the email controlfile for the branch.
        """
        try:
            return (self.branch.control_files.get_utf8("email")
                    .read()
                    .decode(bzrlib.user_encoding)
                    .rstrip("\r\n"))
        except errors.NoSuchFile, e:
            pass

        return self._get_best_value('_get_user_id')

But if you do branch_config.get_user_option('email'), it won't check the
'email' control file.  BranchConfig sets policy for the 'user_id' config
value, not the 'email' key.

Plugins don't need to set policy, because their config values are not
reused by other code.  They can just choose the policy they want when
they get/set the value.  (or, they *ought* to be able to)

But if they want to set policy for their own use, they can subclass
BranchConfig, as pqm-submit does.

>> 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?

When we discussed this in Montreal, I was pushing strongly for
./bzr/branch, and Robert was pushing strongly for
~/.bazaar/locations.conf.  For example, I think 'push_location' should
be in .bzr/branches.conf.

We couldn't agree, so we decided to permit all values in all config files.

There are a few values that must not appear in untrusted files, but
aside from that, I think it still holds true.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFFCVlI0F+nu1YWqI0RAi0gAJ0Xwc03MIzJF/pF8LXskYS9FWusyACfYgoE
g2Jk51AlFCUpMSbv0okGZ0Y=
=QaEv
-----END PGP SIGNATURE-----