This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.
Merge tracking in 1.5
As I mentioned in my previous post, the Subversion project has identified many requirements based on input from both the open source community and from the enterprise data collected by CollabNet from its customers. The requirements as well as the functional and design specifications are available on the Subversion project site.
Subversion’s upcoming 1.5 release is scheduled to deliver the core merge tracking feature with subsequent releases likely extending this. Fundamental to all merge tracking related functionality is the functionality to automatically record what change sets have been copied, or merged, where. On top of this, the 1.5 release will deliver the following functionality:
- Repeated Merge
One of the most frequent definitions of what merge tracking means is the concept of dealing with repeated merges. The requirement is to track which change sets have been applied where, so that users can repeatedly merge branch A to branch B without having to remember the last range of revisions copied. This would also track change set cherry picking by users, so that Subversion won’t accidentally re-merge change sets that are already applied.
- Cherry Picking
Cherry picking is the merging of one or more individual changes from branch A into branch B (as opposed to the merge of all previously unmerged changes). Subversion will provide a way to indicate that the change(s) have been merged into branch B. Such merging must be supported in multiple different directions, for instance if a release branch B is created by copying the trunk, both forward port changes made on branch B into the trunk and backport changes made on the trunk into branch B without confusing the merge tracking algorithm.
- Record Manual Merge
Recording manual merges allows change sets to be marked as merged without having used the ‘svn merge’ sub command to create the defined target revision. This could be to mark a situation when there is no merge tool for the file type and a user merged the changes manually. Also, it should support merge tracking of a change set which is sufficiently different when ported to a different branch that the use of ‘svn merge’ is no longer appropriate.
Example scenarios requiring this functionality include (a) the actual change you want to apply to the branch has no overlap with its incarnation on the source branch but is conceptually equivalent, (b) only a subset of a change set warrants application, and (c) the branch content has drifted far enough apart to make automatic merging impossible (for instance, because it would generate excessive merge conflicts).
- Rollback Merge
The ability to undo a merge and/or the associated tracking meta data, regardless whether the merge is the result of an automated or manual merge.
- Block/Unblock Change Set
Subversion will be able to protect revisions from accidentally being propagated elsewhere.
- Automated Merge
Subversion will have the ability to automate merges and support interfaces for resolving conflicts and other errors.