Wolfram Nyaa~ wrote on Fri, Apr 20, 2012 at 14:05:17 +0700:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 20.04.2012 1:35, Daniel Shahaf wrote:
> > Wolfram Nyaa~ wrote on Fri, Apr 20, 2012 at 00:32:40 +0700:
> >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
> >>
> >> On 04/19/2012 11:32 PM, Daniel Shahaf wrote:
> >>> For what configuration and what data? Client config? Server
> >>> config? Working copies? Repositories?
> >> Any data from ~/.subversion. Client config as far as I know.
> > Does that entail anything beyond changing
> No, I think
>
OK
> > the default lookup order of config from: /etc/subversion,
> > $HOME/.subversion (as modified by --config-dir) to some other
> > sequence of directories, obtained from $XDG_* envvars?
> I think that the following sequence should be used:
> 1) /etc/subversion
> 2) --config-dir (if set)
> 3) $XDG_CONFIG_HOME/subversion (if XDG_CONFIG_HOME set and not empty)
> 4) $HOME/.subversion
Not quite; --config-dir overrides/replaces $HOME/.subversion/. (This is
how it works today, and I don't see why introducing $XDG_* support
should change that part of the semantics.)
>
> > Is it safe to use those envvars whenever they are set?
> According to FDO specification,
> [snip part of the spec describing how to handle missing/empty envvars]
Doesn't answer my question. Perhaps there is a competing spec that also
uses the XDG_* vars in another manner? Perhaps using those envvars
would break backwards compatibility somehow?
(How could that be? Perhaps a recent Linux distro decides to make bash
set the XDG_CONFIG_HOME whenever it starts; this will cause pre-commit
hook scripts to inherit that envvar.)
>
> > Is it possible for them to be set but for the user not to want
> > them used to find config files?
> In such case user should redefine or clear them I think
Not all users have root on the boxes they use svn on. Perhaps someone
uses a box where their admins set XDG_* envvars for them but for some
reason they don't want use those (for svn)? Can that happen?
>
I'm not opposed to the idea, by the way. I'm just reviewing the design
and trying to ensure we don't break A's use-case while implementing B's
new feature.
Cheers,
Daniel
Received on 2012-04-20 09:29:19 CEST