Why doesn't svn merge --ignore-ancestry work twice in this scenario, when svn diff+patch does?

Question

I'm trying to replace my svn merging workflow — which is usually svn diff , sometimes some manual editing of the patch, and then patch — with actual svn merge . But I'm seeing some unexpected behavior, and I can't find an explanation in any of the SVN documentation on-line. Here's my scenario:

1. New repository (rev. 0)
2. Created a blank file called file in trunk (rev. 1)
3. Copied trunk to branches/branch1 (rev. 2)
4. In branches/branch1, changed file to read "abcdefg" and committed (rev. 3)
5. Back in trunk, ran:

svn merge -c3 ^/branches/branch1 . --ignore-ancestry

So far, so good. file in trunk contains "abcdefg". And trunk did not get updated with any mergeinfo, since I used --ignore-ancestry. To verify, I run:

svn pg svn:mergeinfo .

which prints out nothing. Great. So now I want to apply the change in r3 again . So I run:

svn merge -c3 ^/branches/branch1 . --ignore-ancestry

This command does nothing . Prints out no output, does not change file , and does not add any mergeinfo. If I do the same thing with my old diff-and-patch workflow, like this:

svn diff -c3 ^/branches/branch1 | patch

Then file is updated with the change again. And since the change amounted to just:

    --- file    (revision 2)
    +++ file    (revision 3)
    @@ -0,0 +1 @@
    +abcdefg

applying it again just makes file contain two lines of "abcdefg", as intended.

~~~

I know this shouldn't be a common workflow, but I feel like I need to understand what svn merge is actually doing in situations like this before I can comfortably adopt it. (No need espousing the benefits of svn merge — I'm already on board.)

Thanks!

Answer 1

Merge works by comparing the two files to merge and force you to reconcile the differences (and when using ancestry it is many times easier of course when files are related). If the files are identical nothing happens. It seems that Subversion considers that a conflict between "old file" and "successor file" is won by the successor. On any real content with no succession, you will get a conflict to fix with a merge tool. --ignore-ancestry might indeed ignore svn:mergeinfo property while keeping implicit path based history information when it helps trivially, the documentation is not explicit on that point.

On the other hand, your patch workflow is flowed and it is why it doubles the text content: in absence of context (though context is wished in unified patch format, there is none actually in your case), the patcher thinks it is a good idea to apply the patch again, though the right approach is typically that of SubVersion in this case. Another patcher tool might have noticed the absence of context and consider this as the necessity of "start-of-file" / "end-of-file" context to be enforced, patch would have failed then.