Does Subversion merge require an “old style”, although everything seems modern?

Question

I recently migrated from the old subversion server / repository to the latest version 1.8.9. A new repository was created from scratch on the new server, and the old data was imported from scratch (we checked the code from the old repository, exported it locally to remove all SVN bindings and checked it in the new one in the new repository).

Everything seemed beautiful.

We have been using the new repository for several months. I recently went to combine a branch in the trunk. He dumped loads of terrible tree conflicts. I could not understand this. The line and branch should be synchronized (everything in the trunk was also in the branch, the only new code was the code in the branch that we tried to combine). Out of sheer frustration, I clicked Do reintegrate instead of automatic merge (old style) :

Now click merge worked ?!

Why do not I understand? Does anyone explain why this happened and / or what are the differences between the two types of mergers? There seems to be no documentation of what this means.

The only thing I can see, which may be a little unusual, is that at some point we merged with the torso into the industry (some changes in the “emergency” were probably made to live).

Relevant version numbers:

 subversion : 1.8.9 Tortoise: 1.8.8 Repository : V6 

Answer 1

I would like to know what are the practical differences between the "old style" merger and the "new style"

The TortoiseSVN manual has not yet been updated to cover the new automatic merge reintegration feature, but still contains instructions for the old workflow (called the “old style”) when you explicitly indicate that you are performing merge reintegration. Here is the difference between the old style and the new style in TortoiseSVN:

1. Old style = svn merge --reintegrate . In Subversion 1.7 and later, you had to explicitly indicate that you are merging during reintegration by adding the --reintegrate to the command line.

2. New style = svn merge . The --reintegrate option --reintegrate deprecated in Subversion 1. 8+. Whether the merge is reintegrated or not is determined automatically by the Subversion client. However, there are 3 preconditions - your working copy

   • cannot have local edits,
   • can't swap ways
   • working copy should not be a mixed version .

A new merge with automatic reintegration is described in the Subversion 1.8 release notes: Merge with automatic reintegration (option --reintegrate is deprecated) .

This feature is also described in SVNBook 1.8 | Reintegration of the branch . You can compare the chapter with the version of SVNBook 1.7 to understand the difference in workflows between the Subversion 1.7 and 1.8 releases.

The differences in behavior between TortoiseSVN 1.7 (“old style”) and 1.8 (“new style”) were well summarized by Bob Archer on the TortoiseSVN user mailing list .

An explanation of why this caused conflicts using the new style but not using the old style is also desirable.

Not seeing the state of the working copy after both merges (with and without --reintegrate ), it is difficult for me to say what happened afterwards and why the --reintegrate indication obviously changed the behavior). I assume that SVN 1.8 was not able to detect the reintegration merge, so you had to run it explicitly.