You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Matt Blais <mb...@yummage.com> on 2003/08/13 03:05:03 UTC
'svn status' problems with wildcards (Windows)
'svn status' seems to get very confused by wildcards in wc paths (in
Windows XP). I have not done any similar testing with other 'svn'
commands. I am just using the regular WinXP CMD.EXE - no other shell.
# Here's what we're working with:
N:\NAV\Devel> ls tmp*
tmp.183
tmp2.183
tmpAIRP.3bj
tmpAIRP.cpp
tmpOAP.3bj
tmpOAP.cpp
tmpSTPP.3bj
tmpSTPP.cpp
tmp: # Notice this 'tmp' is a dir
devel
wnav.h
# The next cmd should catch the tmp* files as well as
# the 'tmp' dir, but appears to only be processing the dir:
N:\NAV\Devel> svn delete tmp*.*
svn: Path is not a working copy directory
svn: 'tmp' is not a working copy
# Notice this cmd works OK here, but DOESN'T work
# later after marking the files for deletion:
N:\NAV\Devel> svn st tmp*.cpp
tmpAIRP.cpp
tmpOAP.cpp
tmpSTPP.cpp
N:\NAV\Devel> svn delete tmp*.cpp
D tmpAIRP.cpp
D tmpOAP.cpp
D tmpSTPP.cpp
# This cmd worked before the delete, but now it
# doesn't (should show the items marked for deletion)!
# Looks like it's only getting the 'tmp' dir again:
N:\NAV\Devel> svn st tmp*.cpp
svn: The filename, directory name, or volume label syntax is incorrect.
svn: check_path: problem checking path "tmp*.cpp"
# Still not getting the files marked for deletion:
N:\NAV\Devel> svn st tmp*.???
? tmp
? tmp.183
? tmp2.183
? tmpAIRP.3bj
? tmpOAP.3bj
? tmpSTPP.3bj
# Items marked for deletion show up here
# (no wildcards used):
N:\NAV\Devel> svn st -q
M airparse.cpp
M data.cpp
M navlog.cpp
M switch.cpp
D tmpAIRP.cpp
D tmpOAP.cpp
D tmpSTPP.cpp
M turnpt.cpp
# Are we confused yet??
N:\NAV\Devel> svn --version
svn, version 0.26.0 (r6550)
compiled Aug 1 2003, 07:35:50
P.S. Don't ask me, "Does CVS do the same thing?" because it doesn't
matter: Subversion is supposed to be BETTER than CVS (in EVERY respect
;-)
Anyway, I know you're still going to ask, so to save you the trouble the
answer is, "I don't know, because I don't have a CVS repository to try
it with."
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 'svn status' problems with wildcards (Windows)
Posted by cm...@collab.net.
Ben Collins-Sussman <su...@collab.net> writes:
> "Matt Blais" <mb...@yummage.com> writes:
>
> > 'svn status' seems to get very confused by wildcards in wc paths (in
> > Windows XP). I have not done any similar testing with other 'svn'
> > commands. I am just using the regular WinXP CMD.EXE - no other shell.
>
> CMD.EXE has no support for wildcards. The convention on win32 is for
> commandline apps to *each* implement their own wildcard support,
> through some common DLL.
>
> Subversion hasn't gotten around to doing that yet... there was an open
> issue on this, but can't seem to find it at the moment.
That's because I did the job. :-) Slipped it right by ya...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 'svn status' problems with wildcards (Windows)
Posted by Ben Collins-Sussman <su...@collab.net>.
"Matt Blais" <mb...@yummage.com> writes:
> 'svn status' seems to get very confused by wildcards in wc paths (in
> Windows XP). I have not done any similar testing with other 'svn'
> commands. I am just using the regular WinXP CMD.EXE - no other shell.
CMD.EXE has no support for wildcards. The convention on win32 is for
commandline apps to *each* implement their own wildcard support,
through some common DLL.
Subversion hasn't gotten around to doing that yet... there was an open
issue on this, but can't seem to find it at the moment.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 'svn status' problems with wildcards (Windows)
Posted by cm...@collab.net.
cmpilato@collab.net writes:
> > # The next cmd should catch the tmp* files as well as
> > # the 'tmp' dir, but appears to only be processing the dir:
> >
> > N:\NAV\Devel> svn delete tmp*.*
> > svn: Path is not a working copy directory
> > svn: 'tmp' is not a working copy
>
> Are you sure it's not just hitting this first and failing before
> trying to move on to the other tmp* files?
I just confirmed that a similar operation on Linux fails the same way
because it first tries to operate on an unversioned thing, and rather
than skip it (like it should), it halts the whole operation.
I guess we should file an issue for this, unless there's a volunteer
out there who wants to take a stab and making the code in
libsvn_client/delete.c call the "skip" notification on unversioned
targets (and then continue to the next target).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 'svn status' problems with wildcards (Windows)
Posted by cm...@collab.net.
Jack Repenning <jr...@collab.net> writes:
> At 9:53 AM -0500 8/14/03, cmpilato@collab.net wrote:
> >If you use wildcards at the commandline, those wildcards are expanded,
> >not by Subversion, but by something else. On Unix, if that something
> >else can't find something to expand the wildcards to, it expands them
> >to nothing.
>
> Different Unix shells have different policies about this. Some have
> configurable settings on what to do, dating back to the archaeological
> csh "set no noglob".
Ooookay, so thanks for the historical background. But the *point* was
... well, whatever -- if you missed it, that's too bad.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 'svn status' problems with wildcards (Windows)
Posted by Jack Repenning <jr...@collab.net>.
At 9:53 AM -0500 8/14/03, cmpilato@collab.net wrote:
>If you use wildcards at the commandline, those wildcards are expanded,
>not by Subversion, but by something else. On Unix, if that something
>else can't find something to expand the wildcards to, it expands them
>to nothing.
Different Unix shells have different policies about this. Some have
configurable settings on what to do, dating back to the
archaeological csh "set no noglob".
--
-==-
Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
o: 650.228.2562
c: 408.835-8090
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 'svn status' problems with wildcards (Windows)
Posted by cm...@collab.net.
"Matt Blais" <mb...@yummage.com> writes:
> > > # Are we confused yet??
> >
> > Hate to say it, but you seem to be -- about how wildcards work. :-)
>
> Actually I think my confusion is due to the counter-intuitive behavior
> of 'svn st':
>
> If you invoke 'svn st' without any args, it appears to list all
> "repository items" in .svn (including 'svn delete'ed items no longer
> present in the wc);
>
> But when invoked with a wildcard path, 'svn st' appears to only find
> items that currently exist in the wc. While this difference in behavior
> is perhaps 'logical', it is certainly subtle, and confusing to those who
> do not understand the underlying mechanism.
I can see how that might seem counter-intuitive. But you're missing
the point. Subversion's core libraries do not expand wildcards -- on
non-Windows platforms, the OS does this, and on Windows, we link with
a stub library that does this for us. The OS and stub library know
nothing of version control -- the only know about the filesystem
sitting underneath you.
If you use wildcards at the commandline, those wildcards are expanded,
not by Subversion, but by something else. On Unix, if that something
else can't find something to expand the wildcards to, it expands them
to nothing. On Windows, that something else appears to punt and just
hand off the unexpanded wildcards to the program. *Regardless*, you
are gonna get error messages when you use wildcards and there's
nothing in the filesystem with which to expand them. This is not a
flaw in Subversion -- its a simple fact that holds true in every
single piece of software that doesn't do its own wildcard expansion
(which is the majority of softwares in the world, I'd bet).
Let's go back to your examples:
> > > N:\NAV\Devel> ls tmp*
> > > tmp.183
> > > tmp2.183
> > > tmpAIRP.3bj
> > > tmpAIRP.cpp
> > > tmpOAP.3bj
> > > tmpOAP.cpp
> > > tmpSTPP.3bj
> > > tmpSTPP.cpp
When you typed 'ls tmp*', the OS immediately turned that into:
ls tmp.183 tmp2.183 tmpAIRP.3bj tmpAIRP.cpp tmpOAP.3bj tmpOAP.cpp \
tmpSTPP.3bj tmpSTPP.cpp'
And then the 'ls' program said, "Oh, you want me to list 8 files? No
sweat." And it does.
> > > # Notice this cmd works OK here, but DOESN'T work
> > > # later after marking the files for deletion:
> > >
> > > N:\NAV\Devel> svn st tmp*.cpp
> > > tmpAIRP.cpp
> > > tmpOAP.cpp
> > > tmpSTPP.cpp
Yep, the OS turns this into 'svn st tmpAIRP.dpp tmpOAP.cpp
tmpSTPP.cpp', and Subversion says, "Oh, you want me to run status on 3
files? No sweat." And it does.
> > > N:\NAV\Devel> svn delete tmp*.cpp
> > > D tmpAIRP.cpp
> > > D tmpOAP.cpp
> > > D tmpSTPP.cpp
Same thing, except now it's, "Oh, you want me to delete 3 files? No
sweat." And, as you can imagine, it does.
> > > N:\NAV\Devel> svn st tmp*.cpp
> > > svn: The filename, directory name, or volume label syntax is
> > > incorrect.
> > >
> > > svn: check_path: problem checking path "tmp*.cpp"
Now, this command doesn't expand at all. There's nothing which
matches the patten tmp*.cpp. So, in a last-ditch attempt to save
humanity, the OS just hands off the unexpanded wildcard. Subversion
looks for a file named "tmp*.cpp", can't find one, and tells you as
much.
Do I really need to continue with this, or are you starting to see how
wildcards work yet?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: 'svn status' problems with wildcards (Windows)
Posted by Matt Blais <mb...@yummage.com>.
> > # Are we confused yet??
>
> Hate to say it, but you seem to be -- about how wildcards work. :-)
Actually I think my confusion is due to the counter-intuitive behavior
of 'svn st':
If you invoke 'svn st' without any args, it appears to list all
"repository items" in .svn (including 'svn delete'ed items no longer
present in the wc);
But when invoked with a wildcard path, 'svn st' appears to only find
items that currently exist in the wc. While this difference in behavior
is perhaps 'logical', it is certainly subtle, and confusing to those who
do not understand the underlying mechanism.
This is apart from the bug causing it to choke on a non-repository dir.
> -----Original Message-----
> From: cmpilato@localhost.localdomain
> [mailto:cmpilato@localhost.localdomain] On Behalf Of
> cmpilato@collab.net
> Sent: Wednesday, August 13, 2003 10:09 AM
> To: Matt Blais
> Cc: 'Subversion Dev'
> Subject: Re: 'svn status' problems with wildcards (Windows)
>
>
> "Matt Blais" <mb...@yummage.com> writes:
>
> > # Here's what we're working with:
> >
> > N:\NAV\Devel> ls tmp*
> > tmp.183
> > tmp2.183
> > tmpAIRP.3bj
> > tmpAIRP.cpp
> > tmpOAP.3bj
> > tmpOAP.cpp
> > tmpSTPP.3bj
> > tmpSTPP.cpp
> >
> > tmp: # Notice this 'tmp' is a dir
> > devel
> > wnav.h
> >
> >
> > # The next cmd should catch the tmp* files as well as
> > # the 'tmp' dir, but appears to only be processing the dir:
> >
> > N:\NAV\Devel> svn delete tmp*.*
> > svn: Path is not a working copy directory
> > svn: 'tmp' is not a working copy
>
> Are you sure it's not just hitting this first and failing
> before trying to move on to the other tmp* files?
>
> > # Notice this cmd works OK here, but DOESN'T work
> > # later after marking the files for deletion:
> >
> > N:\NAV\Devel> svn st tmp*.cpp
> > tmpAIRP.cpp
> > tmpOAP.cpp
> > tmpSTPP.cpp
> >
> > N:\NAV\Devel> svn delete tmp*.cpp
> > D tmpAIRP.cpp
> > D tmpOAP.cpp
> > D tmpSTPP.cpp
> >
> >
> > # This cmd worked before the delete, but now it
> > # doesn't (should show the items marked for deletion)!
> > # Looks like it's only getting the 'tmp' dir again:
> >
> > N:\NAV\Devel> svn st tmp*.cpp
> > svn: The filename, directory name, or volume label syntax is
> > incorrect.
> >
> > svn: check_path: problem checking path "tmp*.cpp"
>
> Wildcards only expand to things that the system can find.
> 'svn delete' removed the working files from the working copy,
> so there's nothing left there to be expanded. The same thing
> happens in Unix, by the way.
>
> > # Still not getting the files marked for deletion:
> >
> > N:\NAV\Devel> svn st tmp*.???
> > ? tmp
> > ? tmp.183
> > ? tmp2.183
> > ? tmpAIRP.3bj
> > ? tmpOAP.3bj
> > ? tmpSTPP.3bj
>
> Again, because they aren't present for the wildcard expansion
> syntax to expand.
>
> > # Items marked for deletion show up here
> > # (no wildcards used):
> >
> > N:\NAV\Devel> svn st -q
> > M airparse.cpp
> > M data.cpp
> > M navlog.cpp
> > M switch.cpp
> > D tmpAIRP.cpp
> > D tmpOAP.cpp
> > D tmpSTPP.cpp
> > M turnpt.cpp
> >
> >
> > # Are we confused yet??
>
> Hate to say it, but you seem to be -- about how wildcards work. :-)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 'svn status' problems with wildcards (Windows)
Posted by cm...@collab.net.
"Matt Blais" <mb...@yummage.com> writes:
> # Here's what we're working with:
>
> N:\NAV\Devel> ls tmp*
> tmp.183
> tmp2.183
> tmpAIRP.3bj
> tmpAIRP.cpp
> tmpOAP.3bj
> tmpOAP.cpp
> tmpSTPP.3bj
> tmpSTPP.cpp
>
> tmp: # Notice this 'tmp' is a dir
> devel
> wnav.h
>
>
> # The next cmd should catch the tmp* files as well as
> # the 'tmp' dir, but appears to only be processing the dir:
>
> N:\NAV\Devel> svn delete tmp*.*
> svn: Path is not a working copy directory
> svn: 'tmp' is not a working copy
Are you sure it's not just hitting this first and failing before
trying to move on to the other tmp* files?
> # Notice this cmd works OK here, but DOESN'T work
> # later after marking the files for deletion:
>
> N:\NAV\Devel> svn st tmp*.cpp
> tmpAIRP.cpp
> tmpOAP.cpp
> tmpSTPP.cpp
>
> N:\NAV\Devel> svn delete tmp*.cpp
> D tmpAIRP.cpp
> D tmpOAP.cpp
> D tmpSTPP.cpp
>
>
> # This cmd worked before the delete, but now it
> # doesn't (should show the items marked for deletion)!
> # Looks like it's only getting the 'tmp' dir again:
>
> N:\NAV\Devel> svn st tmp*.cpp
> svn: The filename, directory name, or volume label syntax is incorrect.
>
> svn: check_path: problem checking path "tmp*.cpp"
Wildcards only expand to things that the system can find. 'svn
delete' removed the working files from the working copy, so there's
nothing left there to be expanded. The same thing happens in Unix, by
the way.
> # Still not getting the files marked for deletion:
>
> N:\NAV\Devel> svn st tmp*.???
> ? tmp
> ? tmp.183
> ? tmp2.183
> ? tmpAIRP.3bj
> ? tmpOAP.3bj
> ? tmpSTPP.3bj
Again, because they aren't present for the wildcard expansion syntax
to expand.
> # Items marked for deletion show up here
> # (no wildcards used):
>
> N:\NAV\Devel> svn st -q
> M airparse.cpp
> M data.cpp
> M navlog.cpp
> M switch.cpp
> D tmpAIRP.cpp
> D tmpOAP.cpp
> D tmpSTPP.cpp
> M turnpt.cpp
>
>
> # Are we confused yet??
Hate to say it, but you seem to be -- about how wildcards work. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org