On 13.11.2021 00:05, C. Michael Pilato wrote:
WARNING: This is a /total/ drive-by post as I skim the thread.
Are there any svn:auto-props syntaxes that are legal .ini but not
legal for auto-props? I'm thinking of the use of a forward slash
character. Could the format be extended such that a key/propname
under the [auto-props] section that starts with '//' (convenient
comment-esque) indicates some parsing option flag?
*[auto_props]*
*// accept_gnu_extension = true*
*// some_other_keyword_that_does_something_else = 3.14
!(CMakeLists).txt = svn:mime-type=text/plain
CMakeLists.txt = svn:mime-type=text/x-cmake*
Another total drive-by, as I'm not actually looking at the code right
now: but if memory serves, we just look for the separator (= or :) and
accept anything from the start of the line to there as the property name.
This is even documented:
https://cwiki.apache.org/confluence/display/SVN/Configuration+File+Syntax
There's a formal syntax definition there, so anyone who wants to
introduce extensions can check them against those rules.
-- Brane
On Fri, Nov 12, 2021 at 5:23 PM Eugeny Sosnovsky
<eugeny.sosnov...@silverfirsoftware.com> wrote:
Hello again,
One solution that comes to mind would be something like the
following: allow *svn:auto-props* to have certain keywords at the
beginning, which, if present, modify the matching behavior? I
don't mean keyword-value pairs (which the code could confuse for
being patterns to automatically assign SVN properties to), but
literally keywords. Something along the lines of:
*accept_gnu_extensions
some_other_keyword_that_does_something_else
#
!(CMakeLists).txt = svn:mime-type=text/plain
CMakeLists.txt = svn:mime-type=text/x-cmake*
The parser of the *svn:auto-props* property would have to get more
complicated of course, but I don't think there is a possibility of
an existing *svn:auto-props* having such a keyword? (And yes,
something similar could be done to *svn:ignore* as well.)
Another option would be to add a property (e.g.,
*svn:auto-props-modifiers* and *svn:ignore-modifiers* or something
to that effect) that would only contain such keywords, and would
propagate recursively to subdirectories in the same way
*svn:auto-props* does. Then if someone already has
*svn:auto-props* that work for them, they wouldn't have to do
anything - but if they later want to add new ones with GNU
extensions, they can set these additional keywords only in the
directories where they want the extensions activated.
Another option would be to have a modifier to the *svn add*
command that would make use of GNU extensions in *svn:auto-props*.
(And perhaps a client-side setting, or again, an SVN property like
the above, that would automatically activate it.) Something like
*svn add --auto-props-ext <path>*. The downside of this option is
that if one forgets that the *svn:auto-props* that apply to the
path being added make use of GNU extensions, the command would
still work, but the result would be undesired.
Another option would be to add another reserved property like
*svn:auto-props-ext*, yes, but it seems to me like the first
option above is easier. *svn:auto-props-ext* would definitely have
to take precedence over *svn:auto-props*, simply because it can be
more specific than *svn:auto-props* can be, due to the GNU extensions.
I can see about allocating some resources to implementing this
feature if a solution is agreed upon.
Eugeny
On Fri, Nov 12, 2021 at 1:30 PM Daniel Sahlberg
<daniel.l.sahlb...@gmail.com> wrote:
Den fre 12 nov. 2021 kl 13:57 skrev Eugeny Sosnovsky
<eugeny.sosnov...@silverfirsoftware.com>:
>
> To whom it may concern,
> On October 21, 2021, I have inquired on the SVN user mailing
list about any means to use glob patterns in svn:auto-props
that would be more powerful than the Unix fnmatch patterns it
currently uses.
>
> The need to do so was driven by a desire to have different
svn:auto-props settings for "CMakeLists.txt" (a script file
written in the CMake language), and all other "*.txt" files
(general plain text files). It's not too significant in this
particular case, in that they are both plain text files, but I
can imagine a scenario where the inability to set one property
for a specific set of files with a given extension, and
another property for all other files with this extension,
would be limiting. The fnmatch glob syntax does not easily
allow this, but the GNU extensions to it allow, for example,
the use of "!(CMakeLists).txt", which will match anything that
"*.txt" would match, except "CMakeLists.txt". For those
unfamiliar with the GNU extensions, this is a very good
summary (written here for a Python library that duplicates the
functionality):
> https://facelessuser.github.io/wcmatch/fnmatch/
>
> I looked at the SVN DesignNotes wiki, and was unable to find
any entries for something like this. So here I am requesting
this feature. Please let me know if you have any questions
about it. Looking forward to hearing from you!
I'm making another quote [1] from the same e-mail thread as in
your
last message:
> On 11.06.2020 09:42, Branko Čibej wrote:
> > About feature design -- unfortunately we can't just invent
a syntax that
> > would invert the meaning of the glob patterns in
svn:ignore, as that
> > would break backward compatibility. Any ideas for a
solution would be
> > most welcome.
I'm not opposing the idea but implementing the GNU extensions
might
break someone's existing svn:auto-props. It would obviously be
possible to make a compile time switch but I don't know how
many are
rolling their own releases.
Anyhow, please feel free to submit an idea for a new solution and
preferably a patch. Maybe a new svn:auto-props-ext? (In which case
there should also be companion svn:ignore-ext etc. and a
precedance
rule)
Kind regards,
Daniel
[1]
http://mail-archives.apache.org/mod_mbox/subversion-users/202006.mbox/%3ced8b17ea-4116-8007-d660-74ac06791...@apache.org%3e
>
> Eugeny Sosnovsky
> Chief Engineer at Silver Fir Software
>
>
