[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn:auto-props: property specified in a parent dir but not specified in a subdir

From: Stefan Hett <stefan_at_egosoft.com>
Date: Tue, 18 Oct 2016 12:15:43 +0200

On 10/18/2016 12:06 PM, Branko Čibej wrote:
> 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.
>
> 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.
>
> -- Brane
Maybe it's possible to extend the grammar to provide a way to include
inherited settings without breaking backwards compatibility?
Aka something like:
:inherit:;*.txt = svn:eol-style=native

-- 
Regards,
Stefan Hett
Received on 2016-10-18 12:15:54 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.