subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Shahaf <>
Subject Re: Feature request: expand wildcards
Date Tue, 04 Jan 2011 20:22:18 GMT
It's hacky, but:

  svn commit --changelist :glob:'*.foo'

where the "changelist" is then interpreted as a glob pattern
(let's say apr_fnmatch()).


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
> <>
> 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
> D
> % 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
> % echo hello >>
> % svn commit *.foo   # will commit only
> 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 <>

View raw message