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
> > 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
Received on 2012-04-20 09:29:19 CEST