On 12.06.2020 08:24, Matt Simmons wrote:
> Have you considered a pre-commit hook to deny anything not matching
> your rule?

A pre-commit hook doesn't see the contents of the working copy, it's
completely unsuitable for this use case.

-- Brane


> On Thu, Jun 11, 2020 at 11:21 PM Branko Čibej <br...@apache.org
> <mailto: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!" 

Reply via email to