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.
Received on 2016-10-13 02:20:45 CEST