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, <hwri...@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
