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

svn:auto-props: property specified in a parent dir but not specified in a subdir (was: Re: Cannot add files due to hierarchical RDC svn:auto-props when matching rules merge properties between text and binary file types)

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Sun, 16 Oct 2016 23:45:10 +0000

[ 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.



¹ https://subversion.apache.org/docs/release-notes/1.8.html#repos-dictated-config
Received on 2016-10-17 01:47:06 CEST

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