Re: Output of 'svn ls' does not explicitly indicate directory path

[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

Feature request: debugging option?

[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