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>
