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 <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2010-08-06 20:09:06 CEST