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>
> >
