On Fri, Mar 2, 2012 at 01:01, Greg Stein <gstein_at_gmail.com> wrote:
> On Fri, Mar 2, 2012 at 00:47, Greg Stein <gstein_at_gmail.com> wrote:
>>
>> On Mar 2, 2012 12:33 AM, <hwright_at_apache.org> wrote:
>>>
>>> Author: hwright
>>> Date: Fri Mar 2 05:33:22 2012
>>> New Revision: 1296056
>>>
>>> URL: http://svn.apache.org/viewvc?rev=1296056&view=rev
>>> Log:
>>> In the client-side ra Ev2 shim callbacks, make sure we handle copyfrom
>>> paths
>>> correctly.
>>>
>>> Current number of test failures over ra_svn: 357
>>>
>>> * subversion/libsvn_client/util.c
>>> (fetch_props_func, fetch_kind_func, fetch_base_func): Detect and
>>> appropriately
>>> munge copyfrom urls as paths.
>>
>> Woah... wait a second. How did a URL get into the callback? I really think
>> these callbacks should have a single semantic: relpath. But why should we
>> continue the client monstrosity of "maybe path; maybe URL".
>>
>> ???
>>
>> This change seems to paper over a URL leaking into the callbacks. That
>> doesn't seem right.
>
> Looking more into this, the shims should accept an "anchor_url" and if
> they receive a URL in the copyfrom_path, then it should turn that URL
> into a relpath from that anchor. And *then* invoke the callback.
>
> IOW, I think the original bug is that a URL is passed into
> ev1->add_file(copyfrom_path). The shim should strip that down to a
> relpath before invoking the callback.
And replying to myself one more time... :-)
Yes, I know that the delta editor spec allows a URL to be passed as
that parameter. But I don't think we should propagate it into the
callbacks. Messy.
Cheers,
-g
Received on 2012-03-02 07:03:52 CET