Menu
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
936
In Subversion terminology, the general act of replicating changes from one branch to another is called merging, and it is performed using various invocations of the svn merge subcommand. In the examples that follow, we're assuming that both your Subversion client and server are running Subversion 1.7 (or later).
Reverse Merge - Use Subversion reverse merge to roll back a change or multiple changes that have been committed to the repository, and then apply this to your working copy.
In the From URL option, you should specify the branch to which you want to merge. For example, assume that there are 2 branches, branch A and branch B , and you want to merge branch B to branch A . In TortoiseSVN, click on Merge option and then select Merge two different trees option.
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:
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.
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
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.
100
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
