On Feb 2, 2005, at 7:00 AM, Steve Cohen wrote:
> I guess I don't see the point of the svn list command at all, because
> svn status seems to be more informative and useful.
That's exactly what I was going to say to you: why are you running
'svn ls' on a working copy at all? What's the point? 'svn status' is
far more useful for working copies. And you already have the normal
'ls' command to see the contents of your working copy.
The reason 'svn ls' exists is to *browse repositories*. It's meant for
those times when you don't have a working copy at all, and want to poke
around a repository remotely. Originally it only operated on URLs.
It's equivalent to TortoiseSVN's "repos browser" feature.
In summary: stop using 'svn ls' on a working copy. It's not telling
you *anything* about the working copy. It's telling you about old
trees in the server. 'svn status' is the thing you're looking for.
>
> with regular "ls" as we've all come to know and love it, if you list a
> directory, and then list a single file within that directory the
> listings for that file are identical. In svn ls, this is not
> necessarily the case.
>
> I understand what is going on; what I don't understand is why the
> authors of svn want it this way.
>
We don't "want" ls to behave this way. It's just part of the larger
paradigm of directory versioning. The idea of mixed-working-revisions
in a working copy isn't anything new -- CVS does it all the time. But
now you've got working-revisions on *directories*, which complicates
things.
Suppose you have a working copy all at r5. Then you commit foo.c,
creating r9. What should happen to your working revisions? Should
the whole working copy now be at r9? Surely foo.c should be at local
revision 9. But what about the parent dir? Surely we can't blindly
bump it to r9, because people may have added or deleted things, and the
revision of a directory defines a specific list of properties and
children. Your working copy has no idea whether it actually has r9 of
the directory or not. Therefore, until you run 'svn up', your working
revisions aren't going to be changed.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Feb 2 15:13:33 2005