[Svnmerge] incorrect merge of moved item

[Archie Cobbs]

On 11/10/06, bert.robben at agfa.com <bert.robben at agfa.com> wrote:
> I'm using svnmerge to merge changes from the trunk to my branch. On my
> latest merge, I noticed the following:
>
> (1) I changed file A.
> (2) I committed these changes in my branch.
> (3) Somebody else moved file A in the trunk to another directory. This was
> done as a correct move (i.e. the file still has its history in the trunk).
> (4) I do an svnmerge merge in my branch to get the changes from the trunk
> (5) I now see that file A is correctly moved, but the version is exactly
> like the one in the trunk. All my changes are thrown away.
>
> Is this the correct behaviour?

AFAICT this is a limitation/bug in the underlying functionality of
"svn merge". SVN doesn't really have a "move", it just has "delete"
and "copy".

So you can't merge a "move". Instead, you merged the "delete" and then
the "copy", and the "copy" gave you a copy of the same original (i.e.,
from the trunk) rather than a copy of the version in your branch.

So while this behavior is less than desirable, it's really a SVN
problem, not an svnmerge problem.

I'd love to see it get fixed in any case.

A related issue in my mind is: what is the correct way to support
inter-repository merges? E.g. suppose you wanted to "mirror" another
repository inside your own (merging in updates continually over time),
but also do some local mods to it. The "copy" operation is again the
sticking point.

-Archie

__________________________________________________________________________
Archie Cobbs      *        CTO, Awarix        *      http://www.awarix.com