[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Foreign repository checking seems less than robust

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Tue, 27 Jan 2009 15:04:49 +0000

On Thu, 2009-01-22 at 11:45 -0800, Miles Crawford wrote:
> It appears that, when executing a merge, a repository is deemed a "foreign
> repository" based on a simple match of the url.
>
> This is often wrong. A DNS search domain, multiple hostnames, etc can all fool
> subversion into thinking it is using a foreign repos when this is not the case.
>
> Wouldn't it be just as easy to use the Repository UUID to make this
> determination?
>
> I'm trying to spark some discussion to meet the Buddy policy to
> support this issue:
> http://subversion.tigris.org/issues/show_bug.cgi?id=3361

Hi Miles. Thanks for transferring to the mailing list, and sorry that
none of us have responded yet.

I agree that this enhancement should be made. (And yes, I see that it
could be considered a defect rather than an enhancement.)

Although the problem sounds obvious, it is extremely useful to have a
concrete example to work with in order to be clear about the details.

Ways in which the two URLs could differ...

  * I guess an example of a "DNS search domain" situation is when
<http://robert.mydomain.net/> can also be addressed from within
mydomain.net as <http://robert/>.

  * As for "multiple hostnames", let's say the machine "robert" can also
be addressed by the alias "bob".

  * The path part of the URL could also have aliases.
<http://robert.mydomain.net/repos/> could be an alias for
<http://robert.mydomain.net/var/svn-data/public-repos/>.

  * Two URLs with different schemes could also point to the same
resource. (I have a half memory that there is something different about
the problem or its consequences if the schemes differ. Does that ring a
bell with anyone?)

Now we want things like this to work:

[[[
TRUNK=http://robert.mydomain.net/repos/trunk

svn checkout http://bob/repos/branches/branch-a wc

svn merge $TRUNK wc/

svn commit -m "Merge recent changes from trunk." wc/
]]]

I assume:

  * The present result (with Subversion 1.5.x) is that Subversion
assumes the source and destination are different repositories, and so
performs a non-tracking merge.

  * The desired result is that Subversion recognises the source and
destination as the same repository and performs a merge-tracking merge.

Is that right?

There is another variation: the "two-URL" merge, in which you specify
the "left" and "right" source URLs separately. For example:

[[[
REPOS=http://robert.mydomain.net/repos
TAG2=$REPOS/tags/tag-v2
TAG3=http://bob.mydomain.net/repos/tags/tag-v3

svn checkout $REPOS/branches/branch-a wc

svn merge $TAG2 $TAG3 wc/

svn commit -m "Upgrade this branch from v2 to v3." wc/
]]]

In this case too, we should properly detect whether the left and right
source URLs are in the same repository. (Does Subversion just refuse to
do the merge at all if it thinks they are not?) I mention this case
separately because I can see in Subversion's source code that slightly
different comparisons are used, and also it is probably not such an
important or frequent use case.

It doesn't look hard to start fixing (or improving) this. At first
glance, the code looks like it is all in
<subversion/libsvn_client/merge.c>, where some statements like
"sam_repos = (strcmp(this_url, that_url) == 0)" can be seen.

Also it would be very useful to figure out how to generate multiple URLs
for the same repository in our test framework, and write a test (or some
tests) for these cases in <subversion/tests/cmdline/merge_tests.py>.

- Julian

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1059207
Received on 2009-01-27 16:04:52 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.