Den tors 21 okt. 2021 kl 09:31 skrev Eugeny Sosnovsky <
eugeny.sosnov...@silverfirsoftware.com>:
> To whom it may concern,
> The SVN Book version 1.8 states, that if at a given path, *svn:auto-props*
> contains two or more file patterns that can match the same file, and such a
> file is added, then "there is no way to know" which pattern will be applied
> (and therefore, which pattern's corresponding properties the file will gain
> upon addition). The example gives patterns "**.c**" and "**.cpp*".
>
I would interpret "no way to know" as "there is no guarantee" regarding the
current or any future implementation.
In testing with SVN 1.12 (CollabNet build), I've found that the first
> pattern will always take precedence. Is this indeed reliable (i.e., will
> the first match always take precedence over others, if the other matching
> patterns are all found in the same path's *svn:auto-props*), or have I
> just been lucky (i.e., to see consistency)?
>
There is no randomness in the code so you can probably expect it to perform
consistently within a certain version of the program (given the same
parameters), but no explicit guarantee. Any other version or any other set
of parameters might yield different results.
And a followup question - if indeed there is no way to reliably control the
> pattern precedence, then does this mean that there is no way to, e.g., have
> one set of properties apply to "*CMakeLists.txt*" , and another to all
> other "**.txt*" files? Bash globbing syntax would allow
> *!(CMakeLists).txt* to match all **.txt *files EXCEPT *CMakeLists.txt*,
> but I believe these more advanced globbing pattern elements (*!()*, *{}*,
> and the like) do not apply to *svn:auto-props*, correct?
>
There is some part of the glob syntax that allows for negated character
classes. I was looking for it (see [1] and followup messages) and in my
case it was too difficult to make a suitable glob but it might be possible
in your case.
Kind regards
Daniel
[1]
http://mail-archives.apache.org/mod_mbox/subversion-users/202006.mbox/%3c9116ee39-1f64-5d75-8a5a-3bcf35542...@apache.org%3e
