On 06.08.2010 19:50, Hyrum K. Wright wrote:
I'm doing some more thinking about repository-dictated configuration,
and one of the things I'd like some discussion on is the order of
configuration overrides. The consensus is that the repository can not
be sure that it's dictated configuration is received and respected by
the client, so it should treat whatever config it sends as purely
suggestive. We currently have several (implemented or proposed)
sources for configuration information, and I think they should be
searched in the following order:
* Client site-wide configuration (/etc/subversion)
* Client user-specific configuration (~/subversion, 'svn --config-dir')
* Repository-dictated configuration (as described above)
* Explicit configuration supplied by the client application
('svn --config-option', or Eclipse configuration options)
Not every location contains every bit of config, of course, but in the
case of conflicts, the most recent encountered value sticks. In other
words, a client could override repository-dictated configuration
options by using 'svn --config-option', or the (as yet unimplemented)
equivalent facility for other API consumers.
I think that repository-dictated configurations should override client
configs. This is what I think most corporations would expect.
Maybe there could be two client configs: one used as a default if no
corresponding repo-dictated config is available, and then one to
explicitly override the repo-dictated config.
Something like this:
* Client site-wide configuration (/etc/subversion)
* Client user-specific configuration (~/subversion, 'svn --config-dir')
* Explicit configuration supplied by the client application
('svn --config-option', or Eclipse configuration options)
* Repository-dictated configuration (as described above)
* forced configuration by the client (e.g., svn --override-repo-config)
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
