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