You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Greg Stein <gs...@gmail.com> on 2012/04/16 23:35:38 UTC
Re: svn commit: r1326696 - in /subversion/trunk/subversion/libsvn_client:
add.c client.h commit.c copy.c delete.c prop_commands.c util.c
On Mon, Apr 16, 2012 at 13:50, <hw...@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?
Re: svn commit: r1326696 - in /subversion/trunk/subversion/libsvn_client: add.c client.h commit.c copy.c delete.c prop_commands.c util.c
Posted by Thomas Åkesson <th...@akesson.cc>.
On 17 apr 2012, at 02:26, Hyrum K Wright <hy...@wandisco.com> wrote:
> On Mon, Apr 16, 2012 at 5:22 PM, Greg Stein <gs...@gmail.com> wrote:
>> On Mon, Apr 16, 2012 at 18:04, Stefan Sperling <st...@elego.de> wrote:
>>>
>>> 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.
I did some work on this list and on the wiki trying to outline an approach to resolve the Unicode normalisation issues that Subversion experiences on OS X. I second that repos_relpath is the preferred canonical name of nodes and local_*path should be avoided, if the approach I outlined is of interest.
I think it would be of value to both Ev2 and the Unicode discussion if you could review the wiki article. It would be unfortunate to bring forward (into Ev2) any assumptions about paths that can never be safe on a normalising file system.
http://wiki.apache.org/subversion/NonNormalizingUnicodeCompositionAwareness
Thanks!
Re: svn commit: r1326696 - in /subversion/trunk/subversion/libsvn_client:
add.c client.h commit.c copy.c delete.c prop_commands.c util.c
Posted by Hyrum K Wright <hy...@wandisco.com>.
r1327597 approaches the problem from a different angle, partially
inspired by Greg's comment. We just fetch the relpaths for the
various commit items before doing the commit, shove them into a hash
mapping that to the appropriate abspath, and then let the shim
callbacks use the hash to find their way back home. That way, we
avoid the need to do any computation of abspaths in the shim
callbacks, with all of its attendant ills.
Seems to work pretty good.
-Hyrum
On Tue, Apr 17, 2012 at 3:56 AM, Greg Stein <gs...@gmail.com> wrote:
> This is a lot of design work to compensate for losing "file.c".
>
> IMO, the short answer is: stop converting to repos_relpath for all cases. If
> we don't lose local_abspath, then we can get all the base info.
>
> On Apr 17, 2012 4:29 AM, "Julian Foad" <ju...@btopenworld.com> wrote:
>>
>> Hyrum K Wright wrote:
>>
>> > On Mon, Apr 16, 2012 at 5:22 PM, Greg Stein wrote:
>> >> On Mon, Apr 16, 2012 at 18:04, Stefan Sperling 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 wrote:
>> >>>>> On Mon, Apr 16, 2012 at 13:50, <hw...@apache.org> wrote:
>> >>>>>> +++ subversion/trunk/subversion/libsvn_client/util.c
>>
>> In this function:
>>
>> static svn_error_t *
>> rationalize_shim_path(const char **local_abspath,
>> struct shim_callbacks_baton *scb,
>> const char *repos_relpath,
>> apr_pool_t *result_pool,
>> apr_pool_t *scratch_pool)
>>
>> >>>>>>...
>> >>>>>> + svn_wc__get_wc_root(&wcroot_abspath, scb->wc_ctx,
>> >>>>>> + scb->anchor_abspath, ...);
>> >>>>>> + svn_wc__node_get_url(&wcroot_url, scb->wc_ctx,
>> >>>>>> + wcroot_abspath, ...);
>> >>>>>> +
>> >>>>>> + relpath = svn_uri_skip_ancestor(wcroot_url, node_url, ...);
>> >>>>>> + *local_abspath = svn_dirent_join(wcroot_abspath, relpath, ...);
>> >>>>>
>> >>>>> Won't this join() fail in a switched working copy?
>> >>>
>> >>> [...] 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) [...]
>>
>> From those inputs we could generate a list of WC paths whose base matches
>> that repos_relpath at some revision, and a list of WC paths whose copy-from
>> origin matches that repos_relpath at some revision.
>>
>> A repos_relpath only identifies a node when it is paired with a revision
>> number.
>>
>> *** Let's try to keep a repos_relpath with the revision number at which it
>> exists, in all our APIs. ***
>>
>> From a wc_ctx and a pathrev_t (which is repos_root, revision, and URL
>> which is logically equivalent to having the repos_relpath) we could report a
>> list of WC paths whose base or copy-from origin matches that location.
>> That's what you need here.
>>
>> The ultimate aim of that code seems to be to find a pristine node in the
>> WC (that is, a base or copyfrom node, consisting of a node kind, props,
>> and pristine text or symlink target).
>>
>> For that, you don't need a list of all such WC nodes, you just need one.
>> You need a reference to "a repository node that is stored in the WC".
>>
>> Returning a WC abspath is insufficient, unless it also says whether it's
>> found a base or a
>> copyfrom. (Unless the implementation is restricted to one or the other;
>> but it's not evident that it should be restricted.)
>>
>> Imagine for a moment that the WC data storage were laid out with NODES
>> containing references to a new REPOS_NODES table that is indexed by
>> (repos_id, rev, repos_relpath) and whose other columns are (kind, props,
>> checksum, symlink_target). Then all you want is a reference into that
>> table.
>>
>> Would it help to think of an API along those lines, even without actually
>> having structured the WC DB in that way?
>>
>>
>> >> 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.
>>
>> Agreed, although I don't know if it's feasible to gather and store that
>> information before we reach the code in question.
>>
>> > 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.
>>
>>
>> - Julian
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/
Re: svn commit: r1326696 - in /subversion/trunk/subversion/libsvn_client:
add.c client.h commit.c copy.c delete.c prop_commands.c util.c
Posted by Greg Stein <gs...@gmail.com>.
This is a lot of design work to compensate for losing "file.c".
IMO, the short answer is: stop converting to repos_relpath for all cases.
If we don't lose local_abspath, then we can get all the base info.
On Apr 17, 2012 4:29 AM, "Julian Foad" <ju...@btopenworld.com> wrote:
> Hyrum K Wright wrote:
>
> > On Mon, Apr 16, 2012 at 5:22 PM, Greg Stein wrote:
> >> On Mon, Apr 16, 2012 at 18:04, Stefan Sperling 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 wrote:
> >>>>> On Mon, Apr 16, 2012 at 13:50, <hw...@apache.org> wrote:
> >>>>>> +++ subversion/trunk/subversion/libsvn_client/util.c
>
> In this function:
>
> static svn_error_t *
> rationalize_shim_path(const char **local_abspath,
> struct shim_callbacks_baton *scb,
> const char *repos_relpath,
> apr_pool_t *result_pool,
> apr_pool_t *scratch_pool)
>
> >>>>>>...
> >>>>>> + svn_wc__get_wc_root(&wcroot_abspath, scb->wc_ctx,
> >>>>>> + scb->anchor_abspath, ...);
> >>>>>> + svn_wc__node_get_url(&wcroot_url, scb->wc_ctx,
> >>>>>> + wcroot_abspath, ...);
> >>>>>> +
> >>>>>> + relpath = svn_uri_skip_ancestor(wcroot_url, node_url, ...);
> >>>>>> + *local_abspath = svn_dirent_join(wcroot_abspath, relpath, ...);
> >>>>>
> >>>>> Won't this join() fail in a switched working copy?
> >>>
> >>> [...] 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) [...]
>
> From those inputs we could generate a list of WC paths whose base matches
> that repos_relpath at some revision, and a list of WC paths whose copy-from
> origin matches that repos_relpath at some revision.
>
> A repos_relpath only identifies a node when it is paired with a revision
> number.
>
> *** Let's try to keep a repos_relpath with the revision number at which it
> exists, in all our APIs. ***
>
> From a wc_ctx and a pathrev_t (which is repos_root, revision, and URL
> which is logically equivalent to having the repos_relpath) we could report
> a list of WC paths whose base or copy-from origin matches that location.
> That's what you need here.
>
> The ultimate aim of that code seems to be to find a pristine node in the
> WC (that is, a base or copyfrom node, consisting of a node kind, props,
> and pristine text or symlink target).
>
> For that, you don't need a list of all such WC nodes, you just need one.
> You need a reference to "a repository node that is stored in the WC".
>
> Returning a WC abspath is insufficient, unless it also says whether it's
> found a base or a
> copyfrom. (Unless the implementation is restricted to one or the other;
> but it's not evident that it should be restricted.)
>
> Imagine for a moment that the WC data storage were laid out with NODES
> containing references to a new REPOS_NODES table that is indexed by
> (repos_id, rev, repos_relpath) and whose other columns are (kind, props,
> checksum, symlink_target). Then all you want is a reference into that
> table.
>
> Would it help to think of an API along those lines, even without actually
> having structured the WC DB in that way?
>
>
> >> 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.
>
> Agreed, although I don't know if it's feasible to gather and store that
> information before we reach the code in question.
>
> > 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.
>
>
> - Julian
>
Re: svn commit: r1326696 - in /subversion/trunk/subversion/libsvn_client: add.c client.h commit.c copy.c delete.c prop_commands.c util.c
Posted by Julian Foad <ju...@btopenworld.com>.
Hyrum K Wright wrote:
> On Mon, Apr 16, 2012 at 5:22 PM, Greg Stein wrote:
>> On Mon, Apr 16, 2012 at 18:04, Stefan Sperling 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 wrote:
>>>>> On Mon, Apr 16, 2012 at 13:50, <hw...@apache.org> wrote:
>>>>>> +++ subversion/trunk/subversion/libsvn_client/util.c
In this function:
static svn_error_t *
rationalize_shim_path(const char **local_abspath,
struct shim_callbacks_baton *scb,
const char *repos_relpath,
apr_pool_t *result_pool,
apr_pool_t *scratch_pool)
>>>>>>...
>>>>>> + svn_wc__get_wc_root(&wcroot_abspath, scb->wc_ctx,
>>>>>> + scb->anchor_abspath, ...);
>>>>>> + svn_wc__node_get_url(&wcroot_url, scb->wc_ctx,
>>>>>> + wcroot_abspath, ...);
>>>>>> +
>>>>>> + relpath = svn_uri_skip_ancestor(wcroot_url, node_url, ...);
>>>>>> + *local_abspath = svn_dirent_join(wcroot_abspath, relpath, ...);
>>>>>
>>>>> Won't this join() fail in a switched working copy?
>>>
>>> [...] 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) [...]
From those inputs we could generate a list of WC paths whose base matches that repos_relpath at some revision, and a list of WC paths whose copy-from origin matches that repos_relpath at some revision.
A repos_relpath only identifies a node when it is paired with a revision number.
*** Let's try to keep a repos_relpath with the revision number at which it exists, in all our APIs. ***
From a wc_ctx and a pathrev_t (which is repos_root, revision, and URL which is logically equivalent to having the repos_relpath) we could report a list of WC paths whose base or copy-from origin matches that location. That's what you need here.
The ultimate aim of that code seems to be to find a pristine node in the
WC (that is, a base or copyfrom node, consisting of a node kind, props,
and pristine text or symlink target).
For that, you don't need a list of all such WC nodes, you just need one. You need a reference to "a repository node that is stored in the WC".
Returning a WC abspath is insufficient, unless it also says whether it's found a base or a
copyfrom. (Unless the implementation is restricted to one or the other; but it's not evident that it should be restricted.)
Imagine for a moment that the WC data storage were laid out with NODES containing references to a new REPOS_NODES table that is indexed by (repos_id, rev, repos_relpath) and whose other columns are (kind, props, checksum, symlink_target). Then all you want is a reference into that table.
Would it help to think of an API along those lines, even without actually having structured the WC DB in that way?
>> 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.
Agreed, although I don't know if it's feasible to gather and store that information before we reach the code in question.
> 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.
- Julian
Re: svn commit: r1326696 - in /subversion/trunk/subversion/libsvn_client:
add.c client.h commit.c copy.c delete.c prop_commands.c util.c
Posted by Hyrum K Wright <hy...@wandisco.com>.
On Mon, Apr 16, 2012 at 5:22 PM, Greg Stein <gs...@gmail.com> wrote:
> On Mon, Apr 16, 2012 at 18:04, Stefan Sperling <st...@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 <gs...@gmail.com> wrote:
>>> > On Mon, Apr 16, 2012 at 13:50, <hw...@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/
Re: svn commit: r1326696 - in /subversion/trunk/subversion/libsvn_client:
add.c client.h commit.c copy.c delete.c prop_commands.c util.c
Posted by Greg Stein <gs...@gmail.com>.
On Mon, Apr 16, 2012 at 18:04, Stefan Sperling <st...@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 <gs...@gmail.com> wrote:
>> > On Mon, Apr 16, 2012 at 13:50, <hw...@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?
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.
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.
And no... I don't have suggestions. i haven't dived into this since
raising it last week.
Cheers,
-g
Re: svn commit: r1326696 - in
/subversion/trunk/subversion/libsvn_client: add.c client.h commit.c copy.c
delete.c prop_commands.c util.c
Posted by Stefan Sperling <st...@elego.de>.
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 <gs...@gmail.com> wrote:
> > On Mon, Apr 16, 2012 at 13:50, <hw...@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?
Re: svn commit: r1326696 - in /subversion/trunk/subversion/libsvn_client:
add.c client.h commit.c copy.c delete.c prop_commands.c util.c
Posted by Hyrum K Wright <hy...@wandisco.com>.
On Mon, Apr 16, 2012 at 4:35 PM, Greg Stein <gs...@gmail.com> wrote:
> On Mon, Apr 16, 2012 at 13:50, <hw...@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?
-Hyrum
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/