On 08/06/2010 01:50 PM, 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.
>
> Thoughts?It seems to me like, if we search the list above in the order presented (as you suggest), we pretty much get the worst possible scenario. Maybe it's a wording thing, though. (I'm thinking search-and-stop-on-first-find ... maybe you mean overlay/overwrite configurations in this order, then search the merged results?) Whatever you meant, the corporate customers I've spoken with understand that, so long as they are using open source Subversion clients, anyone can theoretically modify their client to change its behavior. But on the assumption that that is a rare case, they want Subversion to try to treat the repos-dictated config as more than merely suggestive. In other words, they want to be able to reasonably expect that in order to get behavior that opposes the repos-dictated configuration, the user *must* have modified their client or used a client that doesn't honor Subversion's design in this respect. In the past, I've proposed the idea of two repos-dictated configuration sets: one that has the ultimately authority and cannot be overridden without library changes, one that sits in about the slot you've described above. -- C. Michael Pilato <cmpil...@collab.net> CollabNet <> www.collab.net <> Distributed Development On Demand
signature.asc
Description: OpenPGP digital signature
