subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Hofer <>
Subject Re: Cannot add files due to hierarchical RDC svn:auto-props when matching rules merge properties between text and binary file types
Date Fri, 14 Oct 2016 14:01:45 GMT
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

I will submit the suggestion / feature request to your issue tracker. I
understand that doing so is no guarantee it will ever be implemented.


*--Rob HoferSenior Electrical EngineerGS Communication Products

Any Export License Required Information and License Restricted
Third Party Intellectual Property (TPIP) content must be encrypted
and sent to

On Fri, Oct 14, 2016 at 2:17 AM, Johan Corveleyn <> wrote:

> On Thu, Oct 13, 2016 at 2:15 AM, Eric Johnson <> 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

View raw message