Hello Johan,
Separating the binary *.v files from the text based *.v files into separate
directories is exactly what we are doing. The hope was that, with the
introduction of inherited properties (svn:auto-props), we could setup a
different set of auto-props rules for just that one low-level directory
where *.v would mean something "non-standard" from a global/default
auto-props rule defined on the root of the repository.
There are some other file extensions we run into also, such as *.doc (MS
Word document/binary vs MS-DOS "document" (just a text file)), and also
*.lib, which is a common ASIC standard-cell library format (text file), vs
a statically linked library file (binary file).
Interestingly enough, the use case for *.doc works today as is, because the
global rule (default case) is binary, and the exception is a text file.
This works because on the lower level directory where we want *.doc to be a
text file, the mime-type override works, and the other properties such as
svn:eol-style and svn:keywords are being *added*, so the desired effect is
achieved. In the opposite case, where the higher level rule is a text file
(with properties like eol-style and keywords), the lower level rule
(binary) does not work because while the mime-type can be overridden, those
other properties cannot be blocked or removed from the upstream rule. And
then 'svn add' fails because combining either property (eol-style or
keywords) with a binary file results in a client error (and I agree that
behavior should probably remain the same as it is today).
Since the auto-props mechanism does not have a subtractive method of
combining multiple auto-props rule matches, it seems to me that the easiest
path to add such a feature is to define a new value to those existing
properties, such as 'none' or 'ignore' so that it is still additive in
nature to existing auto-props rules (thereby a svn:eol-style=none would
override svn:eol-style=Native). This also has the benefit outside this
particular text vs binary use case - where someone may want to disable
keyword substitution on a lower level directory but currently there is no
way to do that other than disabling auto-props entirely. And today that is
our current workaround for this issue - we simply have to add these files
with --no-auto-props and then add the correct properties manually. With the
introduction of inherited properties though, it seems this can be fully
automated.
I will submit the suggestion / feature request to your issue tracker. I
understand that doing so is no guarantee it will ever be implemented.
Sincerely,
Rob
*--Rob HoferSenior Electrical EngineerGS Communication Products
FPGA319-295-4541Rob.Hofer_at_rockwellcollins.com
<Rob.Hofer_at_rockwellcollins.com>rockwellcollins.com
<http://www.rockwellcollins.com/>*
Any Export License Required Information and License Restricted
Third Party Intellectual Property (TPIP) content must be encrypted
and sent to Rob.Hofer_at_corp.rockwellcollins.com.
On Fri, Oct 14, 2016 at 2:17 AM, Johan Corveleyn <jcorvel_at_gmail.com> wrote:
> 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 16:02:15 CEST