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
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.
-
Select the path of the working copy.
-
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.
-
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.
-
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.
-
Check the Ignore line endings checkbox (optional).
-
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.
-
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.
-
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.