You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by nathan bullock <na...@gmail.com> on 2006/02/19 14:08:46 UTC
svn ls output is slightly vague
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.
(I am using a little old of a client so this may have already been fixed.)
Nathan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Feature request: debugging option?
Posted by Vincent Starre <vs...@comcast.net>.
I see this come up every now and then, usually with regard to some
network problem: "Where is svn hanging?"
Just wondering what the thoughts are among developers about adding a
--debug or --trace or some "extra-verbose" option that we mere mortals
can use to see "ah, it's waiting for a response from xxxxxxxxx! It must
be a xxxxxxxxx problem, then!"
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Output of 'svn ls' does not explicitly indicate directory path
Posted by Julian Foad <ju...@btopenworld.com>.
Julian Foad wrote:
>
> 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.
I looked in to this and hit a problem. The names (and, when recursive, the
paths) printed by "svn ls" are the repository names/paths. In a case like:
> $ svn ls a/ b/
> one
> two
> three
we can't simply prefix the local paths "a/" and "b/" to the repository names
"one" etc., because the local path "a" might not be called "a" in the repository.
Furthermore, "a" and "b" might reside at different levels within the
repository, so there is no known "current working directory" from which to
print relative repository paths. Either we would have to print absolute
repository paths (like "/trunk/blah/a/") or we would have to look up the
repository paths of all of the targets and find their common prefix before
starting to output the results. I don't think absolute paths would be
acceptable as a prefix, since they would often be unwanted and too ugly.
A simple solution is to print a line stating the target's repository path
before the block of output from that target, and for it to be an abolute
path-in-repository:
$ svn ls a/ b/
/trunk/blah/a:
one
/trunk/blah/b:
two
three
Omit the line it if it is a repeat of the previous one, so:
$ svn ls b/two b/three
/trunk/blah/b:
two
three
Possibly omit the line if there is only one target, so:
$ svn ls b/
two
three
(But I see that special case for a single target as being more of a sort of
backward-compatibility thing than really desirable in its own right.)
On the other hand, the prefix-path method has the big advantage of being the
same style that is used by a recursive list, and most other Subversion
commands, so it's worth investing some effort to make that work. I haven't
done that yet.
That is where I've got to in my thinking.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Output of 'svn ls' does not explicitly indicate directory path
Posted by Barry Scott <ba...@barrys-emacs.org>.
On Feb 23, 2006, at 22:58, Julian Foad wrote:
>
>> svn_client_list reports paths relative to the URL of the
>> target. svn_client_ls3 had the problem ambiguity problem described
>> earlier. See the compat wrapper that keeps this broken behaviour.
>
> Thanks for the clarification. It seems that from Barry's point of
> view, if he hadn't seen the new svn_client_list(), the answer he
> needed was "We have already fixed it in the trunk." Sorry for not
> realising that.
Yes thats exactly what I wished to hear. I noticed svn_client_list in
the trunk header
files when I was looking for possible svn 1.4.0 changes but did not
pick up on the significance.
Barry
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Output of 'svn ls' does not explicitly indicate directory path
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Sat, 25 Feb 2006, nathan bullock wrote:
> I don't see this svn_client_list function. I am looking at the 1.3.0 source.
>
> Has it been added since 1.3.0?
>
Yes, it's on trunk.
Thanks,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Output of 'svn ls' does not explicitly indicate directory path
Posted by nathan bullock <na...@gmail.com>.
I don't see this svn_client_list function. I am looking at the 1.3.0 source.
Has it been added since 1.3.0?
Nathan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Output of 'svn ls' does not explicitly indicate directory path
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Thu, 23 Feb 2006, Julian Foad wrote:
> Peter N. Lundblad wrote:
> > On Thu, 23 Feb 2006, Julian Foad wrote:
> > This is not true.
>
> <defensive> From the rest of your message I suppose you mean that I was
> wrong in thinking that the old versions of the API also report enough
> information, and that my response would give Barry the wrong overall
> impression, rather than that any statement was untrue. (By "it" I was
> referring to svn_client_list() throughout.) </defensive>
>
Yes, that's *ture* :-) Hope you didn't feel offended by the words I
choose. All I wanted to do was to point out a factual inaccuracy...
Best,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Output of 'svn ls' does not explicitly indicate directory path
Posted by Julian Foad <ju...@btopenworld.com>.
Peter N. Lundblad wrote:
> On Thu, 23 Feb 2006, Julian Foad wrote:
>>Barry Scott wrote:
>>>
>>>Please fix in svn_client_ls not just workaround in svn client.
>>
>>Er, well, no, I don't think so. The current version of those functions is
>>called svn_client_list() and it reports the information that is required.
>>(Note that svn_client_ls{,2,3} are all deprecated and won't change, but I think
>>they also report enough information.) I don't see that it is broken so I don't
>>see that it needs fixing. Did you want some particular new behaviour from it?
>> You suggested a flag to "turn on the unambiguous path name behavior" but
>>didn't say what this behaviour would be.
>>
>>It reports the absolute path within the repository corresponding to the
>>path it was asked to list, and, if that is a directory, the relative
>>names of the children (and grandchildren if recursive). Thus it doesn't
>>directly report the path that you want to print, but the caller knows
>>how the targets were specified on the command line, and the caller can
>>and should choose how to display the results that are reported,
>>generally by trimming off a certain portion from the beginning of the
>>path.
>
> This is not true.
<defensive> From the rest of your message I suppose you mean that I was wrong
in thinking that the old versions of the API also report enough information,
and that my response would give Barry the wrong overall impression, rather than
that any statement was untrue. (By "it" I was referring to svn_client_list()
throughout.) </defensive>
> svn_client_list reports paths relative to the URL of the
> target. svn_client_ls3 had the problem ambiguity problem described
> earlier. See the compat wrapper that keeps this broken behaviour.
Thanks for the clarification. It seems that from Barry's point of view, if he
hadn't seen the new svn_client_list(), the answer he needed was "We have
already fixed it in the trunk." Sorry for not realising that.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Output of 'svn ls' does not explicitly indicate directory path
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Thu, 23 Feb 2006, Julian Foad wrote:
> Barry Scott wrote:
> > On Feb 22, 2006, at 17:11, Julian Foad wrote:
> >
> > Please fix in svn_client_ls not just workaround in svn client.
>
> Er, well, no, I don't think so. The current version of those functions is
> called svn_client_list() and it reports the information that is required.
> (Note that svn_client_ls{,2,3} are all deprecated and won't change, but I think
> they also report enough information.) I don't see that it is broken so I don't
> see that it needs fixing. Did you want some particular new behaviour from it?
> You suggested a flag to "turn on the unambiguous path name behavior" but
> didn't say what this behaviour would be.
>
> It reports the absolute path within the repository corresponding to the
> path it was asked to list, and, if that is a directory, the relative
> names of the children (and grandchildren if recursive). Thus it doesn't
> directly report the path that you want to print, but the caller knows
> how the targets were specified on the command line, and the caller can
> and should choose how to display the results that are reported,
> generally by trimming off a certain portion from the beginning of the
> path.
>
This is not true. svn_client_list reports paths relative to the URL of the
target. svn_client_ls3 had the problem ambiguity problem described
earlier. See the compat wrapper that keeps this broken behaviour.
Thanks,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Output of 'svn ls' does not explicitly indicate directory path
Posted by Julian Foad <ju...@btopenworld.com>.
Barry Scott wrote:
> On Feb 22, 2006, at 17:11, Julian Foad wrote:
>
>> 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.)
[...]
>> 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.
>
> It would be great to get a fix to this problem.
The multi-target ambiguity or the single-file-in-same-named-dir ambiguity or
both? It would be interesting and useful to know which of these you find
bothersome.
> Please fix in svn_client_ls not just workaround in svn client.
Er, well, no, I don't think so. The current version of those functions is
called svn_client_list() and it reports the information that is required.
(Note that svn_client_ls{,2,3} are all deprecated and won't change, but I think
they also report enough information.) I don't see that it is broken so I don't
see that it needs fixing. Did you want some particular new behaviour from it?
You suggested a flag to "turn on the unambiguous path name behavior" but
didn't say what this behaviour would be.
It reports the absolute path within the repository corresponding to the path it
was asked to list, and, if that is a directory, the relative names of the
children (and grandchildren if recursive). Thus it doesn't directly report the
path that you want to print, but the caller knows how the targets were
specified on the command line, and the caller can and should choose how to
display the results that are reported, generally by trimming off a certain
portion from the beginning of the path.
Note that the biggest and first problem to solve is the multi-target issue, and
this is necessarily an issue for the caller to solve, since this API only takes
a single path.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Output of 'svn ls' does not explicitly indicate directory path
Posted by Barry Scott <ba...@barrys-emacs.org>.
On Feb 22, 2006, at 17:11, Julian Foad wrote:
> 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.
It would be great to get a fix to this problem.
Please fix in svn_client_ls not just workaround in svn client.
svn_client_lsX could gain a new boolean arg to turn on the
unambiguous path name behavior.
Then you could implement svn_client_ls2 setting it to false.
Barry
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Output of 'svn ls' does not explicitly indicate directory path
Posted by Julian Foad <ju...@btopenworld.com>.
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
Output of 'svn ls' does not explicitly indicate directory path
Posted by Daniel Rall <dl...@collab.net>.
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.
This definitely differs from the output of 'ls':
$ mkdir foo && touch foo/foo
$ ls foo && ls foo/foo
foo
foo/foo
$ ls -l foo && ls -l foo/foo
total 0
-rw-rw-r-- 1 dlr dlr 0 Feb 20 08:21 foo
-rw-rw-r-- 1 dlr dlr 0 Feb 20 08:21 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. Directories and files and differentiated between by the
presence of a trailing slash:
$ svn ls versioned-dir/
foo/
bar/
index.html
When invoked with the verbose option, file size is another
differentiator:
$ svn ls --verbose src/versioncontrol/
2390 madan Feb 17 19:47 foo/
1485 cmpilato Jul 11 2005 bar/
1790 madan 7173 Oct 05 15:53 index.html
Nathan, when a user explicitly requests a path, why should Subversion
repeat that path in its output?
> (I am using a little old of a client so this may have already been fixed.)
What version of Subversion are you using? 'svn --version' will tell
you.
Thanks, Dan
Re: svn ls output is slightly vague
Posted by nathan bullock <na...@gmail.com>.
The python svn_client_ls function seems to exhibit this same vagueness.
Nathan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org