On Fri, Aug 6, 2010 at 1:08 PM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
> 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?)
I mean the latter: read a config, overwrite any previous values,
repeat. This is how the current system is set up today, I believe (it
uses apr hashes to store the configuration, and just blindly sets the
values it finds, leading the most recent found to be the functional
value).
> 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.
I dunno. I think that may be a bit too complex for a first pass, and
I think that adding a requirement to hack the library doesn't really
add any value, other than obfuscation. The obfuscated approach may
fool some people, but if they really want to override, they are going
to do it. I'd rather accomplish that via the parsing order than
hacking the library (having to specify 'svn --config-option', seems
like a reasonable barrier).
I just wrote that and then read Greg Hudson's mail elsethread, which
makes me wonder if we need three piles:
* always override from server
* possibly override from server
* never override from server
-Hyrum
Received on 2010-08-06 20:24:18 CEST