On Wed, Mar 10, 2010 at 10:36:13AM +0000, Julian Foad wrote: > On Fri, 2010-03-05, s...@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
