[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: Johan Corveleyn <jcorvel_at_gmail.com>
Date: Mon, 17 Oct 2016 10:18:35 +0200

[ dropped users@, added Paul Burba and Julian Foad, who have worked on
the inherited-props / repos-dictated-config features in the past, and
might have an educated opinion on this :-) ]

On Mon, Oct 17, 2016 at 1:45 AM, Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
>
> [ moving to dev@; please reply to dev@ only ]
>
> Johan Corveleyn wrote on Sat, Oct 15, 2016 at 22:59:28 +0200:
> > 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:mime-type=application/octet-stream
> >
> >
> > C:\autoprops\wc\trunk\dir>echo test>test.txt
> >
> > C:\autoprops\wc\trunk\dir>svn add test.txt
> > svn: E200009: Can't set 'svn:eol-style': file
> > 'C:\autoprops\wc\trunk\dir\test.txt' has binary mime type property
>
> Let's take the the special interaction of svn:eol-tyle and non-texty
> svn:mime-type out of the picture; I'll reply on the assumption that the
> parent dir had «*.txt = k1=v1» and the subdir had «*.txt = k2=v2».
>
> I'm not entirely sure what's the expected behaviour here; that is:
> whether the k1 property being present in the overridden *.txt entry but
> absent from the overriding *.txt entry should mean (a) that the k1
> setting from the parent (overridden) entry is to be applied, or (b) that
> k1 property is not to be auto-set.
>
> You referenced the 1.8 release notes¹, which reference the wiki design doc,
> which uses the term "conflicts" without defining it. Interpretation (a)
> makes sense if patterns "conflict" when they define different values for
> any one property; interpretation (b) makes sense if patterns "conflict"
> when they define different unordered lists of (propname, propvalue) pairs.
>
> autoprops_tests.py does not enlighten the ambiguity.
>
> Cheers,
>
> Daniel
>
> ¹ https://subversion.apache.org/docs/release-notes/1.8.html#repos-dictated-config

In the "Auto-Props Hierarchy and Precedence" section of the wiki doc
[1] which talks about conflicts and overriding, there is an example of
overriding the svn:eol-style property with another value (for the same
*.c pattern). But indeed no example about overriding the entire
k1=v1;k2=v2;... set for a specific file pattern. So this type of
"overriding" (are different k=v's merged together, or does the entire
set replace the other?) seems to be unspecified.

In case of the OP's problem reported on users@ (see example above),
it's the "replace entire k=v-set behavior" that would be needed to
make it work.

FWIW, it seems also impossible to "unset" svn:eol-style by giving it
an empty value, so that doesn't help (the error is different though
... it seems svn:eol-style does not accept an empty value):

[[[
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>echo test>test.txt

C:\autoprops\wc\trunk\dir>svn add test.txt
svn: E135001: Unrecognized line ending style '' for
'C:\autoprops\wc\trunk\dir\test.txt'
]]]

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'
]]]

[1] http://wiki.apache.org/subversion/Inheritable-Ignores-AutoProps#Auto-Props_Hierarchy_and_Precedence

-- 
Johan
Received on 2016-10-17 10:19:07 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.