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 <gstein_at_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" <julianfoad_at_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, <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
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/
Received on 2012-04-18 20:18:07 CEST