You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Eugeny Sosnovsky <eu...@silverfirsoftware.com> on 2021/11/12 12:50:09 UTC
Feature request: expand the svn:auto-props glob patterns to include
GNU extensions
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!
Eugeny Sosnovsky
Chief Engineer at Silver Fir Software
Re: Feature request: expand the svn:auto-props glob patterns to include GNU extensions
Posted by Nathan Hartman <ha...@gmail.com>.
On Tue, Nov 16, 2021 at 5:41 AM Martin Edgar Furter Rathod
<mf...@apache.org> wrote:
> This config file documentation reminds me on the case problem regarding
> auto-props. Like *.c and *.C may need different properties but that
> can't be configured right now.
>
> What about adding an auto-props file containing the rules and having a
> better suited format. An entry in the configuration could switch between
> old style auto-props section and new style auto-props file.
Instead of svn:auto-props, there might be a
svn:auto-props-file=file_name_here, where that file is versioned and
in the same directory as the svn:auto-props-file property. Similar
features could include svn:ignore-file=file_name_here, etc. But I
don't really like this idea.
The nice thing about properties is that they keep meta information
separate from the files under version control, so rather than
inventing the properties I just mentioned above, which would require
both a property and a file, I'd prefer a new svn:auto-props-ext
(extended) property that would support a more flexible glob syntax.
Users could define both svn:auto-props and svn:auto-props-ext. If both
are present, newer clients would apply svn:auto-props-ext only. If
only svn:auto-props is present, newer and older clients would continue
to use it as before. Older clients would not recognize
svn:auto-props-ext and would simply ignore it.
Cheers,
Nathan
Re: Feature request: expand the svn:auto-props glob patterns to include GNU extensions
Posted by Martin Edgar Furter Rathod <mf...@apache.org>.
On 14.11.21 00:18, Branko Čibej wrote:
> 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
This config file documentation reminds me on the case problem regarding
auto-props. Like *.c and *.C may need different properties but that
can't be configured right now.
What about adding an auto-props file containing the rules and having a
better suited format. An entry in the configuration could switch between
old style auto-props section and new style auto-props file.
- Martin
Re: Feature request: expand the svn:auto-props glob patterns to include GNU extensions
Posted by Branko Čibej <br...@apache.org>.
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
> <eu...@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
> <da...@gmail.com> wrote:
>
> Den fre 12 nov. 2021 kl 13:57 skrev Eugeny Sosnovsky
> <eu...@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-74ac06791f0f@apache.org%3e
>
>
> >
> > Eugeny Sosnovsky
> > Chief Engineer at Silver Fir Software
> >
> >
>
Re: Feature request: expand the svn:auto-props glob patterns to
include GNU extensions
Posted by "C. Michael Pilato" <cm...@red-bean.com>.
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/plainCMakeLists.txt = svn:mime-type=text/x-cmake*
On Fri, Nov 12, 2021 at 5:23 PM Eugeny Sosnovsky <
eugeny.sosnovsky@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_extensionssome_other_keyword_that_does_something_else#!(CMakeLists).txt
> = svn:mime-type=text/plainCMakeLists.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.sahlberg@gmail.com> wrote:
>
>> Den fre 12 nov. 2021 kl 13:57 skrev Eugeny Sosnovsky
>> <eu...@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-74ac06791f0f@apache.org%3e
>>
>>
>> >
>> > Eugeny Sosnovsky
>> > Chief Engineer at Silver Fir Software
>> >
>> >
>>
>
Re: Feature request: expand the svn:auto-props glob patterns to
include GNU extensions
Posted by Eugeny Sosnovsky <eu...@silverfirsoftware.com>.
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_extensionssome_other_keyword_that_does_something_else#!(CMakeLists).txt
= svn:mime-type=text/plainCMakeLists.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 <da...@gmail.com>
wrote:
> Den fre 12 nov. 2021 kl 13:57 skrev Eugeny Sosnovsky
> <eu...@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-74ac06791f0f@apache.org%3e
>
>
> >
> > Eugeny Sosnovsky
> > Chief Engineer at Silver Fir Software
> >
> >
>
Re: Feature request: expand the svn:auto-props glob patterns to
include GNU extensions
Posted by Daniel Sahlberg <da...@gmail.com>.
Den fre 12 nov. 2021 kl 13:57 skrev Eugeny Sosnovsky
<eu...@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-74ac06791f0f@apache.org%3e
>
> Eugeny Sosnovsky
> Chief Engineer at Silver Fir Software
>
>