If corporations want to have configuration override, fine.
But I want a way to disable that completely. I don't necessarily want to
allow a random sourceforge repository to control my auto-props settings for
a wc of that repository.
So. We could have an allow-repos-config switch (parallel to the existing
allow-plaintext-passwords switch), which could be boolean or three-value
(yes/no/ask).
Daniel
(And if the switch is disabled but the repos wants to dictate client-side
config anyway? We could refuse the checkout (corp repos) or allow it anyway
with a warning (sourceforge repos).)
Hyrum K. Wright wrote on Fri, Aug 06, 2010 at 13:23:39 -0500:
> On Fri, Aug 6, 2010 at 1:08 PM, C. Michael Pilato <cmpil...@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
