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.
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.
Cheers,
-g
