Merging describes the process of integrating distinct sets of changes made in separate files or folders into a single, coherent version.
Merging is most commonly performed in combination with branching in order to recombine changes made in parallel by different team members or on different versions.
Changes are always merged into a working copy. This allows merge results to be reviewed and committed (or rejected) as necessary. The resultant changes are then committed in exactly the same way as any other set of changes.
Merge conflicts occur when overlapping changes occur in the files being merged. Such changes cannot be automatically resolved and require manual intervention from the user.
As changes are always merged into working copies, conflict resolution is no different from that required for conflicts resulting from update operations.
Synchronization merging refers to the act of copying of all changes made in one branch to another.
Synchronization merging is a common task when developers utilize feature branches to develop in parallel and in isolation from one another.
In such circumstances it is crucial that changes integrated into trunk are pushed out to active feature branches. This should happen frequently to ensure that the branches don’t diverge too far and to keep reintegration effort to a minimum.
Merge tracking plays an important role in synchronization as it tells Subversion when the branch was last synchronized with its ancestor allowing only subsequent changes to be merged in the process.
The source branch for a synchronization merge is the branch’s ancestor (usually trunk). Changes are merged into a feature branch working copy.
Reintegration merging is closely related to synchronization.
Once work on a feature is complete, the changes implemented on that feature branch need to be reintegrated back into the trunk. Synchronization is a pre-requisite to successful reintegration, i.e. all upstream changes should be integrated into the feature branch before the changes are merged upstream into trunk. Only then can the developer know that their changes are compatible with others made on other branches. Incompatibilities and conflicts should be fixed on the feature branch prior to reintegration.
The source of a reintegration merge is the feature branch. Changes are merged into a working copy for the branch’s ancestor.
Once reintegrated, a branch should no longer be used. In practice this is not a limitation: if any further development is required then a new branch can be created for that purpose.
Cherry-picking is a merge strategy where only certain change sets (i.e. individual revisions) are copied from one branch to another. This contrasts with synchronization merging where one branch is brought up to date with all changes made in another branch.
Cherry-picking is generally used to copy small, localized spot changes from one version to another. For example, bug fixes implemented in a project’s trunk might be cherry-pick merged to a maintenance branch for inclusion in a patch version.
The source of a cherry-picking merge is generally trunk, with changes being merged into a working copy for the destination branch. For example, a bug fixed in the main development branch for version 2.0 is cherry-pick merged from trunk into a working copy for the 2.0.x maintenance branch.
Merge tracking refers to the book-keeping associated with tracking the changes that have been merged into a project’s various branches. The correct tracking of this information is key to successful and efficient synchronization and reintegration merging.
Subversion stores information about merge operations in svn:mergeinfo properties. These properties are automatically updated following synchronization merges and are committed along with changes to the files themselves. svn:mergeinfo properties should be regarded as private to Subversion; there is no need for users to inspect or modify their contents.