On Thu, Oct 13, 2016 at 2:15 AM, Eric Johnson <eric_at_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
Received on 2016-10-14 09:18:17 CEST