Ben Collins-Sussman wrote:
>
> 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?
Because I'm a newbie and just happened to remember svn list before I
remembered svn status. :-)
> 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.
OK, this makes sense, thanks.
>
>>
>> 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.
>
Got it. Thanks for taking the time to explain.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Feb 3 02:41:56 2005