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" <julianf...@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, <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 >
