"Matt Blais" <mblais1@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
Received on Thu Aug 14 16:56:52 2003