On Wed, Mar 10, 2010 at 10:36:13AM +0000, Julian Foad wrote:
> On Fri, 2010-03-05, stsp_at_apache.org wrote:
> > Author: stsp
> > Date: Fri Mar 5 15:57:23 2010
> > New Revision: 919460
> >
> > URL: http://svn.apache.org/viewvc?rev=919460&view=rev
> > Log:
> > Fix issue #3434, "svn patch API should have a patch target filter"
>
> Hi Stefan.
>
> Issue #3434 <http://subversion.tigris.org/issues/show_bug.cgi?id=3434> "
> svn patch API should have a patch target filter" says:
>
> [[[
> svn_client_patch() should have a 'filter' parameter, specifiying one (or
> more?) paths that will get patched. Other paths that are in the svnpatch
> file would not get used if those paths don't match that filter.
>
> This allows the user to select which parts of the svnpatch file to apply
> and which ones not.
> ]]]
>
> This patch appears to have the filter reversed: it lets the user specify
> paths that the filter should REMOVE, which IMO is not so useful.
Why isn't that useful? I think either way (include and exclude) is useful.
> (Using the word "filter" as a verb is ambiguous: it's never clear
> whether you want to keep the big particles that the filter catches or
> the liquid that passes through - or both, in two separate bowls.)
Yes, we're aware of all this.
See http://subversion.tigris.org/issues/show_bug.cgi?id=3599
My plan is to add an --include-pattern option (at the CLI level as well
as the API level), and if both --include-pattern and --exclude-pattern
options have been specified, have the --exclude-pattern option operate on
any files left after one or more --include-pattern options were used to
limit the patch target list to a given list of files.
I'm also planning on renaming the 'glob_filter' parameter of the API
to 'exclude_patterns' so it matches the terminology used by the CLI
and does not say 'filter' anymore.
Stefan
Received on 2010-03-10 11:47:12 CET