Reintegrate a Branch

There are some conditions which apply to a reintegrate merge: Firstly, the server must support merge tracking. The working copy must be of depth infinite (no sparse checkouts), and it must not have any local modifications, switched items or items that have been updated to revisions other than HEAD. All changes to trunk made during branch development must have been merged across to the branch (or marked as having been merged).

The server must support merge tracking.
The working copy must be of depth infinite (no sparse checkouts), and it must not have any local modifications, switched items or items that have been updated to revisions other than HEAD.
All changes to trunk made during branch development must have been merged across to the branch (or marked as having been merged).

This method covers the case when you have made a feature branch. All trunk changes have been ported to the feature branch, and now you want to merge it back into the trunk. Because you have kept the feature branch synchronized with the trunk, the latest versions of branch and trunk will be absolutely identical except for your branch changes. These changes can be reintegrated into the trunk by this method.

It uses the merge-tracking features of Subversion to calculate the correct revision ranges and to perform additional checks which ensure that the branch has been fully updated with trunk changes. The range of revisions to merge will be calculated automatically. This ensures that you don't accidentally undo work that others have committed to trunk since you last synchronized changes. After the merge, all branch development has been completely merged back into the main development line. The branch is now redundant and can be deleted.

Go to menu Tools > Merge ... The Merge wizard is opened:

The Merge Wizard - The Merge Type
Select the option Reintegrate a branch.
Press the Next button. The second step of the Merge wizard is displayed:

The Merge Wizard - Reintegrate Branch
In the From URL field enter the folder URL of the branch or tag containing the changes that you want to integrate.
You may also click the Browse button to browse the repository and find the desired branch. If you have merged from this branch before, then just use the drop down list which shows a history of previously used URLs.

The History button opens the History dialog which allows you to select a revision number of the repository with the changes.
Select the target of the operation.
1. Select the path of the working copy.
2. Select the URL of the repository corresponding to the working copy.
The target panel of the dialog reminds you the location of the target resource from the working copy where the merge result will be saved and its corresponding repository URL.
Press the Next button. The Merge Options step of the wizard is opened:

The Merge Wizard - Advanced Options
Set advanced options if necessary before starting the merge process.
1. Set the depth of the merge operation in the Merge depth combo box.
  You can specify how far down into your working copy the merge should go by selecting one of the following values:
  - Current depth
  - Recursive (infinity)
  - Immediate children (immediates)
  - File children only (files)
  - This folder only (empty)
  The depth term is described in the Sparse checkouts section. The default depth is the depth of the current working copy.
2. Check the Ignore ancestry checkbox (optional). The Ignore ancestry checkbox allows a merge to be applied between a branch and the trunk or between two branches even if they do not share a common ancestry. Normally the branch and the trunk or the two branches that are merged must have a common ancestor revision in the same repository. In case the two merged trees were imported in the repository they are not related in the sense of a common ancestor tree and the merge operation is possible by ignoring the missing common ancestry of the two merged trees.
3. Check the Ignore line endings checkbox (optional).
4. Check the Ignore Whitespaces checkbox (optional). The Ignore line endings and Ignore whitespaces checkboxes allow you to specify how the line endings and whitespace changes should be handled. If they are checked the changes due only to the line endings and whitespaces are ignored. The default behavior is to treat all whitespace and line-end differences as real changes to be merged. Ignore whitespace changes excludes changes which are caused by a change in the amount or type of whitespace, for example changing the indentation or changing tabs to spaces. Adding whitespace where there was none before, or removing a whitespace completely is still shown as a change. If Ignore all whitespaces is checked all whitespace-only changes are excluded.
5. Check the Only record the merge checkbox (optional). If you are using merge tracking support and you want to mark a revision as having been merged, without actually doing the merge here, check the Only record the merge checkbox. You might want to do this for two possible reasons. You make the changes by hand, then mark the change as merged so that the merge tracking algorithm is aware of it. Or you might want to prevent a particular revision from being merged by marking it as already merged. This will prevent future merging.
6. Press the Test merge button (optional). By pressing the Test merge button you do a dry run of the merge operation in order to see what files are affected and how without modifying the working copy at all. This is very helpful in detecting where conflicts may occur.
Press the Merge button. The merge operation is executed.
Optionally resolve the conflicts that were created by the merge operation.
After the merge operation is finished it is possible to have some resources in conflict. This means that some incoming modifications for a resource could not be merged with the current modifications from the working copy. If there are such conflicts, the following dialog will appear presenting you the resources that are in conflict. In this dialog you can choose a way in which every conflict should be resolved.

Merge Conflicts Dialog

The options to resolve a conflict are:
- Resolve later - Used to leave the conflict as it is for manual resolving it later.
- Keep incoming - This option keeps all the incoming modifications, discarding all current ones from your working copy.
- Keep outgoing - This option keeps all current modifications from your working copy, discarding all incoming ones.
- Mark resolved - You should chose this option after you have manually edited the conflict. To do that, use the Edit conflict button, which will bring to you a dialog presenting the conflicting resource's content for current working copy version and the one with the incoming modifications. After manually resolving the conflict, the resource will be marked as resolved.

When the merge is completed it's a good idea to look at the result of the merge in the specified working copy and see if it meets your expectations. Because merging is sometimes complicated, when there are major changes, conflicts may appear.