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 <brane_at_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!"
Received on 2020-06-12 08:25:06 CEST