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.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 > > > > >
