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