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
