On Fri, Mar 2, 2012 at 01:01, Greg Stein <gst...@gmail.com> wrote: > On Fri, Mar 2, 2012 at 00:47, Greg Stein <gst...@gmail.com> wrote: >> >> On Mar 2, 2012 12:33 AM, <hwri...@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
