Tortoisesvn Subversion 1.8 - merge - no more reintegrate a branch option

Question

In tortoiseSvn 1.8 there is no "reintegrate" a branch option. What is the right way to reintegrate a branch in Tortoise Svn 1.8?

In choose merge and then next option:

Then I get next window:

Or am I doing something else wrong?

Solution 1

Just merge branch to any TARGET

Edit

OK, extended answer: "Merge for Dummies" in pictures

Preface

OK, I will not mask or hide used proving ground.

Used in this sample resources:

• Repository "Hello, World" http://mayorat.ursinecorner.ru:8088/svn/Hello/
  • Branch http://mayorat.ursinecorner.ru:8088/svn/Hello/branches/branche-francaise
  • Trunk of repo http://mayorat.ursinecorner.ru:8088/svn/Hello/trunk

• Local directory z:\WC-Trunk (WC of trunk, used in process)
• TortoiseSVN 1.8.1, Build 24570 - 32 Bit

Steps to reproduce

In order to merge branch to trunk, I have to have Working Copy of trunk, thus - trunk's HEAD checkouted to WC-Trunk

z:\WC-Trunk>svn ls
Dr?p?r.ma?ar.sv?nskan.man.eller.smalensk?n.txt
Hello.de.txt
Hello.en.txt
Hello.eo.txt
Hello.fr.txt

it's needed WC

z:\WC-Trunk>svn info
Path: .
Working Copy Root Path: Z:\WC-Trunk
URL: http://mayorat.ursinecorner.ru:8088/svn/Hello/trunk
Relative URL: ^/trunk
...

Start merging

Select "Merge range", because "This method covers the case when you have made one or more revisions to a branch (or to the trunk) and you want to port those changes across to a different branch"

Select all revisions, if otherwise not defined and path to tree in repository, which have to be merged to trunk (our French branch)

Define (if needed) some additional merge options, can test merge in order to detect, will be conflict resolution needed in any form, or just start real merge process at last

Solution 2

It is no longer in TortoiseSVN because Subversion 1.8 deprecated the --reintegrate option. Subversion 1.8 has automatic reintegration handling/detection.

See: Subversion 1.8 release notes, specifically the auto-reintegrate section

Here is the relevant area, for convenience:

Automatic reintegration merge (--reintegrate option deprecated)

During merges which merge all eligible revisions from another branch, Subversion 1.8 will automatically decide whether or not the merge is reintegrating a branch. Therefore, reintegrating a branch does no longer require the --reintegrate option for correct operation.

The --reintegrate option of svn merge is now deprecated and its use is discouraged. To reintegrate a branch, have a clean working copy of trunk and run the following command in its top-level directory:

$ svn merge ^/branches/my-branch

This merge will still perform similar sanity checks which svn merge --reintegrate performed in earlier releases:

• The working copy must not be a mixed-revision working copy.
• The working copy must not have switched subtrees.
• There must be no gaps in revision ranges merged from the reintegration target (e.g. the trunk) to the reintegration source
  (i.e. the branch to be reintegrated).

If any of these conditions are detected, the merge is aborted and the necessary steps must be taken to fix the problem before the branch can be reintegrated. In contrast to a --reintegrate merge, an automatic reintegration merge into a working copy with local modifications is allowed.

Merging to-and-fro between two branches in any order is possible using the automatic reintegration merge (the "keep-alive dance" is no longer necessary). For best results, it is recommended to always merge all eligible revisions, i.e. not using the -r or -c options of svn merge. Merging just a subset of eligible revisions increases the likelihood of problems during future merges.

Using --reintegrate in Subversion 1.8 will force a reintegration merge, whether or not that's the right merge to perform in the given situation.

In your case, you should do the following:

1. Make sure you're using a clean, no modifications, up-to-date trunk working copy as you normally would
2. TortoiseSVN -> Merge on this working copy root
3. Select "Merge a range of revisions"
4. Select the branch you are reintegrating
5. Do not specify a revision range (to merge all eligible revisions)
6. Subversion 1.8 should autodetect the reintegration and perform the same safety checks
7. Proceed with your merge normally

According to the compatibility table, a Subversion 1.8 client can perform this auto-reintegrate as long as your Subversion server and repository format are each version 1.5 or later.

I haven't done an auto-reintegrate yet myself, I'm just going off the release notes.

Solution 3

Hold down Shift key when you are opening context menu, you will see hidden options. There will be TortoiseSVN/Merge reintegrate... in menu.

However you should use new Automatic reintegration merge

Comments

[Jernej Novak]

I have 3 branches to set. From, to and working copy when I select "Merge two different trees"

[Lazy Badger]

@JernejNovak - don't use 2-URL merge, until it really needed

[oldwizard]

This answer is better because of "Do not specify a revision range (to merge all eligible revisions)"

[Fletch]

Thanks for the helpful explanation. I have noticed that in SVN 1.7 merge tracking also works perfectly and I don't see the need to use reintegrate there either. Is it possible to just reintegrate using a normal merge in 1.7 too?

[Ates Goral]

@Fletch I have always referenced this post on the collab.net blog regarding merge reintegration since 1.5. I still use it for branch reintegrations in 1.7 - it basically does a lot of extra safety checks and it HAS found potential issues for me in the past (1.7). Looking closer at the release docs, I think the suggestion would be to upgrade your client to 1.8 (server version only needs to be 1.5+) since auto merge reintegration is a CLIENT-side operation and then you could definitely not worry about it.

[Chucky]

The auto-reintegration feature does not always work seemlessly. When it fails, the merge exhibits some conflicts then stops, asking for the conflicts to be solved before you are allowed to relaunch the merge to continue it. This symptom is relevant enough to push you towards requiring an explicit reintegration merge. Although quite rare, this actually may happen. I've personally experienced it today.

[imclickingmaniac]

Holly! Thank you for SHIFT option. There is a lot more there that really helped me.

[Micer]

Thanks, didn't know about Shift option! Anyway, in TortoiseSVN 1.9.2 there's no Merge reintegrate... anymore.

[R. Schreurs]

At the end of this tutorial you would have all changes in the branch merged into you working copy of trunk, right? What would be normal steps to get rid of the branch altogether? Commit trunk and delete the branch? I did the commit and took a look at the Revision graph. There is a branching curve from trunk to branch at creation. However, there is no indication of reintegration. Does that mean my merge is not detected as a reintegration?

[eaglei22]

What if I have branch, tag, and trunk in my working copy, how do I know the merge is going directly into the trunk, Or how do I specify the merge to the trunk?

[Pere]

Then I'd like to understand what the "Merge two different trees" option is for. According to the manual (tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-merge.‌​html), "Merge two different trees" "is a more general case of the reintegrate method" and mentions that "If you are using this method to merge a feature branch back to trunk, you need to start the merge wizard from within a working copy of trunk". At the same time, it says that "Merge a range of revisions" "is known as a reintegrate or automatic merge". Very confusing indeed, and I wonder what are the differences in the end