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
> *** 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
> 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:57:19 CEST