On Mon, Apr 16, 2012 at 5:22 PM, Greg Stein <gstein_at_gmail.com> wrote:
> On Mon, Apr 16, 2012 at 18:04, Stefan Sperling <stsp_at_elego.de> wrote:
>> On Mon, Apr 16, 2012 at 04:41:49PM -0500, Hyrum K Wright wrote:
>>> On Mon, Apr 16, 2012 at 4:35 PM, Greg Stein <gstein_at_gmail.com> wrote:
>>> > On Mon, Apr 16, 2012 at 13:50, <hwright_at_apache.org> wrote:
>>> >>...
>>> >> +++ subversion/trunk/subversion/libsvn_client/util.c Mon Apr 16 17:50:05 2012
>>> >>...
>>> >> + /* ### We could probably calculate some of this once, and then cache it for
>>> >> + use in this function. */
>>> >> + SVN_ERR(svn_wc__get_wc_root(&wcroot_abspath, scb->wc_ctx,
>>> >> + scb->anchor_abspath,
>>> >> + scratch_pool, scratch_pool));
>>> >> + SVN_ERR(svn_wc__node_get_url(&wcroot_url, scb->wc_ctx, wcroot_abspath,
>>> >> + scratch_pool, scratch_pool));
>>> >> +
>>> >> + relpath = svn_uri_skip_ancestor(wcroot_url, node_url, scratch_pool);
>>> >> + *local_abspath = svn_dirent_join(wcroot_abspath, relpath, result_pool);
>>> >
>>> > Won't this join() fail in a switched working copy?
>>>
>>> Honestly, I haven't thought much about it. Any proposals on how to
>>> work around it?
>>
>> At the very least, you must compare the URL of the node at the calculated
>> local_abspath to the original node_url. If they do not match, the
>> node at local_abspath is switched, so the node you're looking for is not
>> in the WC at the expected location.
>>
>> The node could be somewhere else, though, at a different path which
>> is switched to the original URL you're looking for. Maybe you'll need
>> to add a new libsvn_wc API that tries a bit harder to figure out where
>> the node could be?
I think this may be the answer: a API which takes a wc_ctx, a
repos_root, and a repos_relpath. With that information, we should be
able to resolve a node location (and hence its pristine) without much
difficulty.
> Well... I think the real problem could be that you *already* knew
> where it was. The user may have said "svn foo file.c", where file.c is
> in a switched subdir. Then it gets switch to repos_relpath, and then
> we lose the wc location.
We could pass such information along in the baton, but the problem is
sometime this information changes between the time we construct the
baton and the time we use it, as in the case of committing from
disjunct working copies.
> This is why I was tentative with unequivocally stating Ev2 should use
> repos_relpath. Bert mentioned a couple scenarios where it could
> falter, too. And then I had a couple other concerns around paths in
> the copy/move/rotate APIs.
I probably need to go back and review that discussion. From my early
work on the ev2-export branch, repos_relpaths vastly simplified the
problem space by giving nodes canonical names, both inside the editor
and in the driver / receivers.
> And no... I don't have suggestions. i haven't dived into this since
> raising it last week.
Understood, and I appreciate the eyes you are giving this problem.
There's a *lot* of work to do with revamping the editor, and while
I've got the next one or two steps figured out in my head, there are
still plenty of question marks.
The best thing you (or anybody else reading this) can do, in addition
to review and code, is add tests which exercise questionable cases,
since I'm primarily using the test suite as the standard of
"complete." That's probably not a very good decision. :)
-Hyrum
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/
Received on 2012-04-17 02:27:03 CEST