Merging confuses renamed files

Hi,

I've been playing around with Subversion's merging features and have
found that local changes get clobbered when a merge is run on a file.

Consider this example. We have Bob maintaining the main tree for
package foobar, and his repository is at http://foo.com/somewhere. He
maintains foo.py.

Alice has her own repository for foo.py, which contains a couple of
small changes.

She keeps it up to date with commands like:

svn merge -r 5:7 http://foo.com/somewhere .
svn commit -m 'Updated to r7'

...

svn merge -r 7:15 http://foo.com/somewhere .
svn commit -m 'Updated to r15'

Now, this all goes along happily. Alice's changes follow along as she
tracks the upstream development. But let's say that Bob does this:

svn mv foo.py bar.py
svn commit -m 'Renamed foo.py to bar.py' # Creates rev 17

Later, Candice updates with:

svn merge -r 15:20 http://foo.com/somewhere .

But her changes get lost. bar.py now contains the vanilla upstream,
rather than her patched version. And merge runs cleanly, never
warning of any problem.

My question is: why? Subversion has enough information to duplicate
the upstream changes locally, but doesn't. It appears to be behaving
as if --ignore-ancestry was given to merge, but it wasn't.

Can anybody shed some light on this?

Thanks,
John

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Aug 22 17:34:12 2003