On 10/18/2016 12:29 PM, Daniel Shahaf wrote:
> Branko Čibej wrote on Tue, Oct 18, 2016 at 12:06:32 +0200:
>> On 18.10.2016 09:32, Stefan wrote:
>>> On 10/17/2016 15:37, Branko Čibej wrote:
>>>> On 17.10.2016 14:12, Daniel Shahaf wrote:
>>>>> Johan Corveleyn wrote on Mon, Oct 17, 2016 at 10:18:35 +0200:
>>>>>> Omitting the '=' also doesn't cut it:
>>>>>>
>>>>>> [[[
>>>>>> C:\autoprops\wc\trunk\dir>svn pg svn:auto-props --show-inherited-props
>>>>>> C:\autoprops\wc - *.txt = svn:eol-style=native
>>>>>>
>>>>>> C:\autoprops\wc\trunk - *.txt =
>>>>>> svn:eol-style;svn:mime-type=application/octet-stream
>>>>>>
>>>>>> C:\autoprops\wc\trunk\dir>svn add test.txt
>>>>>> svn: E135001: Unrecognized line ending style '' for
>>>>>> 'C:\autoprops\wc\trunk\dir\test.txt'
>>>>>> ]]]
>>>>> Quoting ~/.subversion/config:
>>>>>
>>>>> [auto-props]
>>>>> ### The format of the entries is:
>>>>> ### file-name-pattern = propname[=value][;propname[=value]...]
>>>>>
>>>>> So the «=value» part is allowed to be omitted entirely, but what are the
>>>>> semantics of that? They don't seem to be documented.
>>>>>
>>>>> It seems to me that we can *define* that if the = sign is absent, then
>>>>> the value of the property will be not "" but NULL.
>>>> Unfortunately the implementation
>>>> (libsvn_client/add.c:all_auto_props_collector()) already explicitly
>>>> handles 'propname' as if it were 'propname=', i.e., sets the value to
>>>> "". Since the "documentation" in the generated config file already
>>>> implies that the '=' can be absend, I'd say this behaviour is pretty
>>>> much set in stone.
>>>>
>>>>
>>>> -- Brane
>>> From a user's point of view I'm also not sure whether a syntax of *.foo
>>> = k1 would be intuitive to read as if that's unsetting the property...
>>> Personally I wouldn't get that behavior tbh, without reading the
>>> documentation.
>> That's a good point. Also from a user's perspective, I'd find it
>> extremely confusing that, having seen an svn:auto-props value containing:
>>
>> *.txt = svn:eol-style=native
>>
>> and then 'svn add'ing foo.txt, to find that the newly added file has,
>> e.g., svn:keywords set because some auto-props value higher up in the
>> tree happens to specify it for the '*.txt' pattern.
>>
> I can easily imagine other scenarios in which the overlaying behaviour
> is not confusing, but expected; for example:
>
> % svn propset svn:auto-props '*.txt = svn:mime=type=text/plain;;charset=UTF-8' Documentation # sic
> % svn propset svn:auto-props '*.txt = svn:eol-style=LF' Documentation/unix
> % svn propset svn:auto-props '*.txt = svn:eol-style=CRLF' Documentation/windows
>
> The output of 'svn help ps' may propagate this expectation, too:
> .
> svn:auto-props -
> ⋮
> Applies recursively to all files added or imported under the directory
> it is set on.
> .
> (The term "recursively" is not qualified or restricted.)
>
>> If we change the behaviour so that a rule for a (case-insensitive)
>> pattern completely overrides a hierarchically previoius rule, we can
>> also introduce the concept of disabling auto-props rules; e.g., just
>> having a
>>
>> *.txt =
>>
>> could mean "do nothing with files matching '*.txt' from this point
>> onwards." I think that would be a quite valuable addition to the
>> auto-props feature set.
> This is a very compelling argument :-) However, I note that it, too, is
> backwards incompatible.
>
> I was thinking of inventing new syntaxes, «*.txt := PROPHASH» for
> override (as you suggest) and «*.txt += PROPHASH» for overlay (as now).
> Released libsvn's interpret these syntaxes as the shell pattern "files
> whose name ends with the 6-character substring '.txt +'".
>
> Cheers,
>
> Daniel
>
FWIW: I favor your approach/syntax to define overrides/additions to
properties over the syntax I brought up in my other mail.
--
Regards,
Stefan Hett
Received on 2016-10-18 12:54:30 CEST