We have a rather common use case where we have an svn:auto-props rule set
globally (set on root of repository) to define source code files as text
based, but also have some files provided by 3rd parties which compress or
encrypt similar files with the same file extension (which we have no
control over), and hence we want to set an svn:auto-props rule locally on
those directories to make those files binary type. But the hierarchical
svn:auto-props rules add properties from multiple definitions of the same
match filter (*.v), and result is a conflicting set of properties that
block the add at the client (eol-style with mime-type=octet-stream).
For example, a binary and text based Verilog file (*.v):
%> file binary.v
binary.v: gzip compressed data, was "binary.v", from Unix, last modified:
Mon Feb 18 19:44:25 2013, max compression
%> file text.v
text.v: ASCII text
The RDC auto-props for this directory shows these Verilog and VHDL types
(local directory expects binary types, global are source-code text files).
%> svn propget svn:auto-props --show-inherited-props .
http://crsvn/gsadc - *.v = svn:eol-style=LF;svn:keywords=Id Revision
Date Author URL;svn:mime-type=text/x-verilog
. - *.v = svn:needs-lock;svn:mime-type=application/octet-stream
Adding the files to SVN control fails, unless --no-auto-props is used
(undesirable work around):
%> svn add binary.v
svn: E200009: Can't set 'svn:eol-style': file '/module/lay/binary.v' has
binary mime type property
%> svn add --no-auto-props binary.v
A (bin) binary.v
%> svn add text.v
svn: E200009: Can't set 'svn:eol-style': file '/module/lay/text.v' has
binary mime type property
%> svn add --no-auto-props text.v
Subversion auto-detects the binary file and at least sets the mime-type,
but other properties are missing because --no-auto-props is the only way to
add the files without error.
%> svn proplist -v binary.v
Properties on 'binary.v':
%> svn proplist -v text.v
%> svn --version
svn, version 1.9.4 (r1740329)
compiled May 18 2016, 12:05:49 on x86_64-unknown-linux-gnu
(Incidentally, the commit will fail because our hook is checking these
svn:auto-props rules and the file must match the binary rules or the text
rule, based on the mime-type). So the only way today to add these files to
SVN is to use --no-auto-props on add, and go into the server and disable
the pre-commit hook during the commit, then put the pre-commit hook back.
Since a pre-commit hook is the only way to enforce the use of auto-props
correctly, disabling the hook is not an optimal solution. Once added to
SVN, the issue never comes up again because the properties do not change,
and the pre-commit hook checks the modifications on future commits based
upon the mime-type (binary or text rules). The issue is only during the
initial add to SVN due to conflicting properties being applied to the file
based on how the svn:auto-props definitions are being interpreted.
1. Make lower level svn:auto-props rules completely override upstream ones,
rather than additively merging properties, for rules with same exact match
filter (local *.v redefines upstream *.v completely).
2. Make SVN ignore properties such as eol-style and keywords when the
mime-type is a binary type rather than issue a fatal error to the
user/client (warning instead that some properties are being ignored).
3. Provide a subtractive property rule to undo an upstream property. E.g.,
svn:eol-style=none, or svn:keyword=none, such that a lower level rule can
unset a property defined upstream (and make svn:eol-style=none behave same
as if svn:eol-style was not applied at all).
Note: Before RDC svn:auto-props (pre 1.8), this use case required having
two entries in the ~/.subversion/config, with one always commented out.
When encountering one type or the other (text or binary), user would have
to uncomment/comment the proper auto-props rule in their config file before
the add, and then change their config back for the normal case. This was
very unwieldly and required careful synchronization of all user runtime
config files and hook scripts and manual intervention by the user during
adds. Hierarchical RDC properties should eliminate this problem, but it
falls a little short because of how hierarchical RDC svn:auto-props rules
merge mutually exclusive properties together. I believe this is very
similar to multiple matches in the ~/.subversion/config runtime file, for
example a *.v rule and a *-rtl.v rule could collide, except now it is
possible to have the very same rule filter (*.v) defined in more than one
location in the subversion hierarchy. See proposed solution #1 as my
desired behavior from the SVN client.
*--Rob HoferSenior Electrical EngineerGS Communication Products
Any Export License Required Information and License Restricted
Third Party Intellectual Property (TPIP) content must be encrypted
and sent to rob.ho...@corp.rockwellcollins.com.