On Thu, Oct 13, 2016 at 2:15 AM, Eric Johnson <e...@tibco.com> wrote: > 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.
Another workaround might be to separate the binary *.v files into a separate directory, completely separated from the textual *.v world (so they are in mutually exclusive parts of the repo). So you can set the correct svn:auto-props applicable to each. FWIW, I think you have a valid usecase, though it's a bit unusual. Of your proposed solutions, I think 1 and 2 are not possible (1 breaks backwards compatibility; and 2 is too risky: failing in this case is the safest behavior). But your 3rd suggestions (introducing some way to subtract or negate svn:auto-props) sounds like it could be a useful enhancement (though I'm not sure how we would define the syntax, without breaking backwards compatibility -- but maybe as a separate new property or something). So: feel free to enter this suggestion / feature request in our issue tracker. (for the record: filing an issue will not magically make it happen -- this is largely a volunteer-driven project -- but at least that way we don't lose track of the request) -- Johan
