Any branching scheme requires the consideration of merging. Up until now, Subversion facilitates merges but does not record them as such in its history information. That is, Subversion does not automatically record, or track, what change sets have been merged where and what revisions were created as a result of merging.  To work around the lack of merge tracking, current best practice is to properly document merges in commit log messages.

Merge tracking is a multi-faceted set of functionality and no single definition exists that is commonly agreed upon. Most users and organizations tend to think of only the subset of features that addresses particular issues they face in their development organizations. Examples of features that are commonly part of merge tracking are to automatically record what change sets exist on what branches, prevent duplicate merges, handle bi-directional merging, support for manual recording of tracking information, block certain change sets from ever being propagated elsewhere, and various reporting capabilities.

Little over a year ago, the Subversion project started to define, design, and implement merge tracking. CollabNet contributed by gathering enterprise requirements for the open source project. In February 2006, we organized a workshop that brought select customers together with the Subversion development team to make an inventory of required functionality.  The Subversion team has taken these requirements and driven the definition, design, and implementation. CollabNet employees continue to take a key role in developing the feature and addressing open issues related to merge tracking.

Subversion’s Merge Tracking requirements, functional specification, design documents, and the current status of the project are available on the Subversion project's merge tracking pages.

In my next post, I will provide an overview of the functionality that the Subversion team intends to deliver in their upcoming 1.5 release.