Daniel Rall wrote:
> On Sun, 19 Feb 2006, nathan bullock wrote:
>
>>If I have a directory structure such as /foo/foo (a file foo inside a
>>directory foo) and I do:
>>
>>svn ls /foo
>>I get output of:
>> 875 nathan 56 Nov 01 19:48 foo
>>
>>If I do 'svn ls /foo/foo'
>>I get output of:
>> 875 nathan 56 Nov 01 19:48 foo
>>
>>So does this mean that the path '/foo/foo' is a subdirectory that
>>contains a file 'foo' which is 56 bytes in size. Or that it is a file
>>'foo' which is 56 bytes in size. I think the output needs to be a
>>little clearer.
Indeed, that output is ambiguous.
> This definitely differs from the output of 'ls':
>
> $ mkdir foo && touch foo/foo
> $ ls foo && ls foo/foo
> foo
> foo/foo
[...]
> I'm dubious that Subversion should bother emulating this "path
> listing" behavior of 'ls'. The output of 'svn ls' does not show the
> requested parent path -- it always shows the contents of the requested
> resource.
That's not quite right. "svn ls" shows the content of the resource only when
the resource is a directory; if the resource is a file it shows the resource
itself. That is the problem. Of course it's intentional, and convenient for
some common use cases, but it's not precise. It's not exactly a bug in itself,
but it leads to a usability bug in some circumstances like Nathan's example above.
> Directories and files and differentiated between by the
> presence of a trailing slash: [...]
> When invoked with the verbose option, file size is another
> differentiator: [present for files, absent for dirs]
Yes, and that's great, but it doesn't help the user to determine the meaning of
the output in Nathan's example. The output shows that there is a file, but it
doesn't indicate whether the file exists at the requested path or as the only
child of the requested path.
> Nathan, when a user explicitly requests a path, why should Subversion
> repeat that path in its output?
As well as that being one way to make the first case unambiguous, here's
another reason why: without it, in a multi-target command, we can't tell where
each listed item resides:
$ svn ls a/ b/
one
two
three
$ ls a/ b/
a/one
b/two
b/three
In both cases, I can think of two reasonable solutions.
1. Prefix the requested path to each file name. The output would then look
like the relevant portion of "svn ls -R". This is also equivalent to the way
"svn status" and "svn proplist" behave. (If this is done just for
disambiguating the multi-target case, any common prefix could be removed, but I
think it would be better to keep it.)
2. For each directory whose content is to be listed, first output a line
indicating which directory's content is about to be listed. This is what Unix
"ls" does, or at least GNU "ls" v5.3.0. This is not such a good solution in
the sense that it isn't how "svn ls -R" currently deals with subdirectories,
which is to prefix their paths, but in other ways it might appeal.
It is pretty certain that the multiple-targets case needs a fix. Daniel's case
of ambiguity in a single target is probably not often a problem in practice and
changing its behaviour is probably more of a problem in terms of backward
compatibility.
I propose we fix the multiple-targets ambiguity, and do so in manner (1).
With that done, we'd be in a stronger position to argue for the same behaviour
to apply to the former case of listing a single item, but we may not want to do
that, or at least not by default.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Feb 22 18:22:00 2006