Your constraints, as currently specified, seem to require actual logic....
Thoughts follow your email.
On 10/12/16 1:44 PM, Rob Hofer wrote:
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
A 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:mime-type
application/octet-stream
%> 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.
Proposed solution:
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.
Only a few options I see:
- different repositories for the binary files vs. the text format.
- improved hook scripts to enforce your desired constraints based on
the content of the incoming added file, rather than just the extension.
You could also create a client side script / tool to check before a commit.
Eric.
