Greg Stein wrote:
> On Wed, Mar 10, 2010 at 07:32, Julian Foad <julian.f...@wandisco.com> wrote:
> >...
> >> @@ -2887,10 +2913,11 @@
> >>
> >> tmp_entry.revision = *(eb->target_revision);
> >>
> >> - if (eb->switch_url)
> >> + if (eb->switch_relpath)
> >> {
> >> - tmp_entry.url = svn_path_url_add_component2(eb->switch_url,
> >> - db->name, pool);
> >> + tmp_entry.url = svn_path_url_add_component2(eb->repos,
> >> + db->new_relpath,
> >> + pool);
> >> modify_flags |= SVN_WC__ENTRY_MODIFY_URL;
> >> }
> >
> > Is that definitely the same as the straightforward conversion which
> > would be to join (eb->repos, eb->switch_relpath, db->name)?
> >
> > I can't figure out whether the code that generates db->new_relpath (in
> > make_dir_baton()) will always have the same result. I'm trying it out
> > by constructing both and comparing them with an assertion, but I can't
> > be sure that all the switch scenarios actually get tested in the test
> > suite.
> >
> > On the other hand, maybe the new "join(repos, new_relpath)" is more
> > correct than what was there before.
>
> Conceptually, yes it is better. We always want to identify items in a
> repository with a <root, relpath> tuple. Consistently.
And correctness-wise, I'm happy now that we've had Bert's and your eyes
on it, and I successfully ran the test suite while asserting that it
produces the same result as join(eb->repos, eb->switch_relpath,
db->name).
> Within wc_db (and hopefully percolating out to libsvn_wc and further),
> we also carry around the repository's UUID, so you'll see lots of
> 3-tuples of <root, relpath, uuid>. And in some cases, we need the
> revision (like with original_*), so you get a 4-tuple.
>
> Even though we do not allow variant repositories within the "same"
> working copy, the wc_db allows for it and should be coded that way. We
> should continue to push those concepts further out. Today, working
> copy subtrees from a separate repository are *distinct* working
> copies. The subtree is labeled as a "working copy root" (per
> svn_wc__check_wc_root). In the future, we can stitch these together
> into one big working copy.
OK.
- Julian
