On Wed, Jan 4, 2012 at 7:30 PM, Paul Burba <ptbu...@gmail.com> wrote:
> On Tue, Jan 3, 2012 at 6:16 PM, Daniel Shahaf <d...@daniel.shahaf.name> wrote:
>> On Tue, Jan 3, 2012, at 17:58, Paul Burba wrote:
>>> Mike Pilato and I have been kicking around some ideas on server
>>> dictated configuration recently and have put our thoughts into a wiki
>>> (full disclosure: this wiki was initially based on Hyrum's thoughts on
>>> the subject in
>>> https://svn.apache.org/repos/asf/subversion/trunk/notes/repos-dictated-config)
>>> :
>>>
>>> http://wiki.apache.org/subversion/ServerDictatedConfiguration
>>>
>>> We're at a point where it's time to solicit some wider feedback, so
>>> please have a look at the wiki and follow-up here with any concerns,
>>> thoughts, suggestions, etc..
>>
>> 1. Under "So, the order in which specific configuration options will be
>> honored where found is:", you say that ~/.subversion/ settings would
>> be overriden by /etc/subversion settings. That's not how the code
>> works today --- i.e., not a compatible change. Typo?
>
> I intended that list to be from highest priority to lowest, just
> clarified that. Also added command-line options to the list at the
> number 2 spot.
I think command-line options should still have number 1 priority, so
overrule the "server-side suggestions". People use command-line
options usually very consciously, when they're trying to do something
special that's outside of the normal usage. So I would expect
command-line options to take priority.
If things need to be enforced, they need to be checked on the
server-side anyway, as already described on the wiki page.
If the command-line options don't take priority, I can see workarounds
appearing based on the following:
>> 2. How would failure to create ~/.subversion/repos/${UUID}/foo be
>> considered? Fatal error? Warning-but-continue?
>
> I'd say the latter, which is what we do now if Subversion cannot
> create the standard run-time config:
"Aha, so if I want my script, which tries to do special things with
command-line options, to overrule the server-side config, let's move
~/.subversion/repos/${UUID}/foo temporarily away, and make the
directory read-only."
Another question: is the server-dictated config still "extendable" by
the client? I.e.: if the server already defines a global svn:ignore
value, can the user still append another pattern? Or for autoprops:
maybe I want to have my own extra autoprops in addition to the ones
that are standardized by my organization ...
I think that would be a quite desirable feature, though I'm uncertain
about the details (should the client be able to decide whether to
override or extend? how? With some special syntax in the config
values? ...). Just wondering ...
--
Johan
