Have you considered a pre-commit hook to deny anything not matching your rule?
On Thu, Jun 11, 2020 at 11:21 PM Branko Čibej <br...@apache.org> wrote: > On 12.06.2020 07:30, Daniel Sahlberg wrote: > > Hi, > > > > Thanks for your quick response! > > > > > > The way I solve a similar case is to set svn:ignore to '*', i.e., to > > ignore everything, then just 'svn add' the files I want under version > > control. It's not ideal, as you'd miss the files you're interested > in. > > > > > > Already doing this. But sometimes we forget to 'svn add' a new file > > which then doesn't show up as modified. User error, surely, but if the > > mistake can be avoided :-) > > > > > > 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. > > > > > > Exactly my thoughts. The only solution I see is to add a new property > > svn:unignore which is applied after (or in conjunction with) the > > svn:ignore property. A file is ignored if it matches the svn:ignore > > glob pattern AND NOT matches the svn:unignore glob pattern. If > > svn:unignore is empty (or non-existent), the behaviour should be > > exactly the same as today. > > > > The code should be reasonably simple (but I have not analyzed if it > > would affect anything in the public interface) - only question if > > maintainers think a new property is a good idea. > > I can't think of a way to solve this without introducing a new property > (actually, two new properties, the other has to be the opposite of > svn:global-ignores). The code would, indeed, be quite simple; the > complex part has already been done, and adding the additional "and not > matches X" logic should be trivial. > > Care to move this over to dev@ with a patch? > > -- Brane > -- "Today, vegetables... Tomorrow, the world!"
