Daniel Shahaf wrote on Tue, Jan 04, 2011 at 22:22:18 +0200:
> It's hacky, but:
> 
>   svn commit --changelist :glob:'*.foo'
> 
> where the "changelist" is then interpreted as a glob pattern
> (let's say apr_fnmatch()).
> 
> Thoughts?
> 

That wasn't hard:

[[[
% $svn st -q
M       subversion/libsvn_wc/adm_ops.c
M       COMMITTERS
% $svn st -q --cl ':glob:*.c'
M       subversion/libsvn_wc/adm_ops.c
%
]]]

Daniel
(still want to hear if people think it's actually a useful addition)


[[[
Index: subversion/libsvn_wc/adm_ops.c
===================================================================
--- subversion/libsvn_wc/adm_ops.c	(revision 1054438)
+++ subversion/libsvn_wc/adm_ops.c	(working copy)
@@ -2175,6 +2175,31 @@ svn_wc__set_file_external_location(svn_wc_context_
 }
 
 
+static svn_boolean_t
+match_globs(const char *local_abspath,
+            apr_hash_t *clhash,
+            apr_pool_t *scratch_pool)
+{
+  /* ### copy-paste of svn_hash_keys().  Just revv it instead. */
+  {
+    apr_hash_index_t *hi;
+    apr_array_header_t *globs;
+
+    globs = apr_array_make(scratch_pool, apr_hash_count(clhash), sizeof(const char *));
+
+    for (hi = apr_hash_first(scratch_pool, clhash); hi; hi = apr_hash_next(hi))
+      {
+        const char *changelist = svn__apr_hash_index_key(hi);
+        if (!strncmp(changelist, ":glob:", 6))
+          APR_ARRAY_PUSH(globs, const char *) = changelist + 6;
+        /* Add more pseudo-changelist types here. */
+      }
+
+    return svn_cstring_match_glob_list(svn_dirent_basename(local_abspath, NULL),
+                                       globs);
+  }
+}
+
 svn_boolean_t
 svn_wc__internal_changelist_match(svn_wc__db_t *db,
                                   const char *local_abspath,
@@ -2200,8 +2225,10 @@ svn_wc__internal_changelist_match(svn_wc__db_t *db
       return FALSE;
     }
 
-  return (changelist
-            && apr_hash_get(clhash, changelist, APR_HASH_KEY_STRING) != NULL);
+  if (changelist && apr_hash_get(clhash, changelist, APR_HASH_KEY_STRING) != NULL)
+    return TRUE;
+
+  return match_globs(local_abspath, clhash, scratch_pool);
 }
 
 svn_boolean_t
]]]

> 
> Ed Avis wrote on Tue, Jan 04, 2011 at 14:48:21 +0000:
> > Hi, this is a feature request for the command-line svn client.  I am posting it
> > here rather than in the issue tracker directly.  It is slightly related to the
> > earlier thread
> > <http://article.gmane.org/gmane.comp.version-control.subversion.user/36113>
> > but not exactly the same issue.
> > 
> > If you remove some files and then commit them, then the 'svn rm' command can
> > take a wildcard but 'svn commit' cannot, for example
> > 
> > % svn rm *.foo
> > D a.foo
> > D b.foo
> > % svn commit *.foo
> > svn: Commit failed (details follow):
> > svn: '/some/where/*.foo' is not under version control
> > 
> > Before a dozen people jump in to reply, I understand that in Unix-like systems
> > wildcard expansion is done by the shell, that there are good reasons why it is
> > done this way, and that the above behaviour is therefore not a bug.  (I am using
> > bash on Linux.)
> > 
> > However, as a convenience to the user, I wonder if it would be more helpful for
> > svn to expand wildcards relative to known files in the repository.  Then in the
> > above case, when '*.foo' does not match any files and the wildcard is passed
> > through unchanged by the shell, svn would expand it and the result would be what
> > the user intended.
> > 
> > I can see that things could get interesting in the case where just some of the
> > files have been removed:
> > 
> > % svn rm a.foo
> > % echo hello >>b.foo
> > % svn commit *.foo   # will commit only b.foo
> > 
> > However, this is arguably not any more surprising than the current behaviour.
> > In fact, it is the current behaviour.  If svn had wildcard support, you would
> > be able to force committing both files by saying
> > 
> > % svn commit '*.foo' # get svn to expand the wildcard itself
> > 
> > As an additional safety catch, when svn expands a wildcard, the user could be
> > prompted that the resulting list of filenames is what was intended.
> > 
> > Wildcard support like this would also make some operations easier; see the FAQ
> > for examples.
> > 
> > If this feature has already been considered by the developers and rejected,
> > I apologize.  I didn't see anything when searching the issue tracker.
> > 
> > -- 
> > Ed Avis <eda@waniasset.com>
> >