You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Ed Avis <ed...@waniasset.com> on 2011/01/04 15:48:21 UTC
Feature request: expand wildcards
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 <ed...@waniasset.com>
Re: Feature request: expand wildcards
Posted by Ed Avis <ed...@waniasset.com>.
Daniel Shahaf <d.s <at> daniel.shahaf.name> writes:
>> No file matching '*.foo' - to expand wildcards, say
>> svn commit --changelist :glob:'*.foo'
>
>This can't be implemented in svn itself: for example, my shell
>simply raises an error (without running the program) if a wildcard
>failed to match
Ah, I see. I use bash and that passes the wildcard through unchanged. I didn't
remember that other shells do it differently.
Still, for the people who use bash and similar shells (which must be the
majority?), svn will see the wildcard and could offer guidance.
--
Ed Avis <ed...@waniasset.com>
Re: Feature request: expand wildcards
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Ed Avis wrote on Wed, Jan 05, 2011 at 12:52:39 +0000:
> Daniel Shahaf <d.s <at> daniel.shahaf.name> writes:
>
> > svn commit --changelist :glob:'*.foo'
>
> From my point of view that would be useful, if combined with a warning message:
>
> No file matching '*.foo' - to expand wildcards, say
> svn commit --changelist :glob:'*.foo'
>
This can't be implemented in svn itself: for example, my shell
simply raises an error (without running the program) if a wildcard
failed to match:
% true *.nonexistent
zsh: no matches found: *.nonexistent
% echo $?
1
%
(the same would hold for s/true/svn/)
> Thanks for producing the patch - I guess it's up to the other developers now.
>
Yep. I'm not fully convinced yet that it's a good idea.
Feel free to shepherd the issue though, e.g., start discussions (on the
appropriate list) to see what improvements are both doable and
acceptable and etc.
> --
> Ed Avis <ed...@waniasset.com>
>
Re: Feature request: expand wildcards
Posted by Ed Avis <ed...@waniasset.com>.
Daniel Shahaf <d.s <at> daniel.shahaf.name> writes:
> svn commit --changelist :glob:'*.foo'
>From my point of view that would be useful, if combined with a warning message:
No file matching '*.foo' - to expand wildcards, say
svn commit --changelist :glob:'*.foo'
Thanks for producing the patch - I guess it's up to the other developers now.
--
Ed Avis <ed...@waniasset.com>
Re: Feature request: expand wildcards
Posted by Stefan Sperling <st...@elego.de>.
On Wed, Jan 05, 2011 at 12:26:30AM +0200, Daniel Shahaf wrote:
> (btw, do we have a way to say "except files in $this changelist"?)
I don't think we do.
Re: Feature request: expand wildcards
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Stefan Sperling wrote on Tue, Jan 04, 2011 at 22:44:49 +0100:
> On Tue, Jan 04, 2011 at 10:47:52PM +0200, Daniel Shahaf wrote:
> > 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)
>
> This is quite similar to the --include-pattern and --exclude-pattern
> options we temporarily had on trunk (for svn patch; they have since been
> removed again).
>
> Do we really need to overload --changelist?
It does the same thing this feature does (specify targets), and
overloading means we don't have to revv the 23 client APIs which use
changelists.
But I'm not sure I like the change myself.
Daniel
(btw, do we have a way to say "except files in $this changelist"?)
Re: Feature request: expand wildcards
Posted by Stefan Sperling <st...@elego.de>.
On Tue, Jan 04, 2011 at 10:47:52PM +0200, Daniel Shahaf wrote:
> 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)
This is quite similar to the --include-pattern and --exclude-pattern
options we temporarily had on trunk (for svn patch; they have since been
removed again).
Do we really need to overload --changelist?
Re: Feature request: expand wildcards
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
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 <ed...@waniasset.com>
> >
Re: Feature request: expand wildcards
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
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 <ed...@waniasset.com>
>