Den ons 17 juni 2020 kl 20:22 skrev Daniel Shahaf <d...@daniel.shahaf.name>:
> > > > > At this point I'd rather wait for Daniel to answer my question and > > > > > clarify his problem statement. > > > > > > > > I rather suspect that XX* and YY* were just general examples, not > > > > concrete ones. > > > > > > So do I, but the solution I posted is generalizable, as you know. > > > > > > > These were indeed just general examples. In practice there will be more > > than two patterns as well. > > > > I must admit I haven't experimented much with the glob pattern > (admittedly, > > I suck at this!) but I have a feeling the complexity will increase > rapidly > > when the number combinations (and variations) increase. > > Yes, it will… but there might be room for, say, a tool that takes as > input a list of patterns and outputs the svn:ignore property value to > use. That won't be hard to write, and the main selling point would be > that it would work under existing releases as well. > > > I think a separate property that is evaluated at the same time as > > svn:ignore is a lot easier to explain ("A file is ignored if the name > > satisfies one pattern in the svn:ignore list and satisfies NO pattern in > > the 'reverse of svn:ignore' property") than a convoluted regex. > > No argument here. I never objected to an additional property, you > know; I just wanted to finish turning that last stone. See you on dev@ ☺ > > > The downside with a new property is that GUI implementors *may* want > > to implement additional support in the GUI for optimum user > > experience. > > I don't see how that's a downside. > I'm going through my open e-mails and realise I never closed this discussion, so I'm going to make a closing comment in case someone else ask the same question and wonder whatever happened. The change in Subversion itself seemed managable but our main tool is TortoiseSVN and it turned out that TSVN is using its own implementation when deciding what files should be suggested for addition. It is using the glob functions in Subversion, but it doesn't go the same code path as, for example, svn status. Since it seems this has only been requested twice in 10+ years I didn't think it was worth the effort to create a patch suggestion for both Subversion and TSVN. Kind regards, Daniel Sahlberg