On Thu, Jan 5, 2012 at 1:56 AM, Daniel Shahaf <danie...@elego.de> wrote:
> Johan Corveleyn wrote on Thu, Jan 05, 2012 at 01:40:40 +0100:
>> 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 ...
>
> What if the server specifies
>
> *.c = svn:eol-style=native
>
> and the user's config specifies
>
> *.c = svn:keywords=HeadURL
> ? Do both of them take effect?
>
>
>
> (This may be what you asked.)
Indeed, that's my question. Or:
Server specifies
global-ignores = *.o ...
User happens to spread *.class files around in his working copy and
wants to "add":
global-ignores = *.class
But, if at some point we might want to allow (well-behaved) clients to
override certain properties (if so allowed by the server), we might
need to make the distinction between "overriding" and "extending".
Maybe some special syntax would help, to indicate extension?
*.c += svn:keywords=HeadURL
or
*.c = ;svn:keywords=HeadURL
or something like that.
Oh, but what about "multi-valued" auto-props:
Server specifies:
*.c = svn:keywords=Author Date
User wants to also add HeadURL as keyword:
*.c += svn:keywords=HeadURL
Hm, that's really an edge case, probably not that interesting :-) ...
(and the problem is somewhat similar with the various ways of
specifying properties that exist today (command-line options, user
config file, system config file, ...))
Maybe "overriding" would also need a special syntax in the future, to
avoid back-compat problems with old config files still lying around:
*.c == svn:keywords=HeadURL
or something like that ...
--
Johan
