Skip to main content
Enterprise Agile Planning Image

This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.

Last Updated May 11, 2007 — Enterprise Agile Planning expert

Merge tracking in 1.5

Enterprise Agile Planning

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.

More from the Blog

View more
Apr 08, 2021

Making IT services more agile

Enterprise Agile Planning
The agile revolution completely transformed how we create digital prod ...
Read More
Feb 14, 2021

Reflecting on the 20th anniversary of the Agile Manifesto

Enterprise Agile Planning
Over the past 20 years, it’s been amazing to watch an idea from ...
Read More
Feb 08, 2021

How does agile apply to an entire organization?

Enterprise Agile Planning
Before we dive into the main subject of this blog post, it is importan ...
Read More
Feb 03, 2021

It took a pandemic to realize why digital transformation actually matters

Enterprise Agile Planning
Before anyone had ever heard of COVID-19, businesses across the globe ...
Read More
Contact Us