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
Received on Thu Feb 23 00:29:33 2006