Bug during (interactive) merging?

Hi,

I noticed an unexpected behaviour during a merge with a recent 1.5
snapshot. I tried to reproduce it but I (at least partly) failed.

Nevertheless here is the story:

* Create a branch as copy of trunk
* Add a file to both, trunk and branch, (same filename and content, but
  no common history)
* Rename the file in trunk
* Remove the renamed file in trunk

* Merge the renaming and removal in trunk to branch.

Since the files in trunk and branch share no common history I'm unsure
whether the merge should conflict. It didn't, OK (I first expected this).

The status in branch is now:
 M .
D file

If I merge first the renaming and after it the removal (without
intermediate commit) I get:

 M .
D file
A + file.old

Is this a bug? At least after reading the changelog and especially
 'svn copy A B ; svn move B C' now the same as 'svn copy A C' (issue #756)
I assume that there should be no other result. It should not matter
whether I split the merge into two merges or not. Right?

I tried to reproduce a situation in my large repository where a merge of
both actions at a time resulted exactly (no svn:mergeinfo change) in:
D file
A + file.old

But please note that I had a conflict in this directory (before the
rename) which I resolved interactive and now I wonder whether this
interactive merge is aquivalent to separate merges. I assume that
without the conflict I would just get:
D file

PS: issue #756 was reopened. Should it stay fixed in the CHANGES file?

Jens

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-06-05 17:56:58 CEST