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
Received on Thu Feb 23 23:58:34 2006