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 <e...@waniasset.com> > >