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

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, <hwright_at_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
Received on 2012-04-17 10:29:41 CEST