Subversion merge requires "Old style" even though all seems up to date?

Question

I recently moved from an old subversion server/repository to the latest version 1.8.9. The new repository was made from scratch on a new server and the old data was imported from scratch (we checked out the code from the old repository, exported it locally to remove all SVN bindings and checked it in a fresh into the new repository).

All seemed fine.

We've been using the new repository for a few months now. I recently went to merge a branch into the trunk. It threw up loads of the dreaded tree conflicts. I couldn't understand this. The trunk and branch should of been in sync (everything in the trunk was also in the branch the only new code was the code in the branch which was what we were trying to merge). Out of sheer frustration I clicked Do reintegrate instead of automatic merge (old style):

Now clicking merge it worked?!

Why I don't get it? Anybody explain why this happened and/or what the differences are between these two merge types? There seems to be no documentation of what this means.

The only thing I can see that could be a little unusual is that we merged up from the trunk to the branch at some point (some "emergency" changes had probably been done to live).

Relevant version numbers:

subversion : 1.8.9
Tortoise: 1.8.8
Repository : V6

Answer 1

I wish to know what are the practical differences between "old style" merging and "new style"

TortoiseSVN Manual hasn't been updated yet to cover the new automatic reintegration merge feature and still contains instructions for the old workflow (the one called 'old style') when you had explicitly specify that you are doing a reintegration merge. Here is the difference of old style and new style in TortoiseSVN:

1. Old style = svn merge --reintegrate. In Subversion 1.7 and older you had to explicitly specify that you do a reintegration merge by appending --reintegrate option to the command-line.

2. New style = svn merge. --reintegrate option is deprecated in Subversion 1.8+. Whether the merge is reintegration or not is determined by Subversion client automatically. There are 3 preconditions, though -- your working copy

   • cannot have any local edits,
   • cannot have switched paths,
   • working copy mustn't be a mixed-revision one.

The new automatic reintegration merge is described in Subversion 1.8 Release Notes: Automatic reintegration merge (--reintegrate option deprecated).

The feature is also described in SVNBook 1.8 | Reintegrating a branch. You can compare the chapter to the SVNBook 1.7 version to understand the difference of the workflow between Subversion 1.7 and 1.8 releases.

Differences in TortoiseSVN 1.7 ('old style') vs 1.8 ('new style) behavior were well summarized by Bob Archer in TortoiseSVN's users mailing list.

also preferably an explanation as to why this caused conflicts using new style but not using old style?

Without seeing the status of the working copy after both merges (with --reintegrate and without it), it is hard for me to tell what happened then and why specifying --reintegrate explicitly changed the behavior). I guess that SVN 1.8 failed to detect reintegration merge, so you had to run it explicitly.