[Svnmerge] incorrect merge of moved item

[Daniel Rall]

On Fri, 10 Nov 2006, Archie Cobbs wrote:

> 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.

Subversion's fs-atomic-renames branch explores what's necessary to put
the underlying support into the file system.  After that's in place,
we can rev Subversion's editor API to take advantage of this new
record of moves.

> 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.

Effectively, a vendor branch.

> The "copy" operation is again the sticking point.

Yes, that's one problem.  I suppose you end up using 'svn diff' and
'patch' and perform the merging manually.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: </pipermail/svnmerge/attachments/20061110/074e978c/attachment-0002.pgp>