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
Received on Thu Mar 2 18:43:56 2006