Surety is performing system maintenance this weekend. Electronic date stamps on new Prior Art Database disclosures may be delayed.
Browse Prior Art Database

Managing Change Histories

IP.com Disclosure Number: IPCOM000225062D
Publication Date: 2013-Jan-23
Document File: 4 page(s) / 70K

Publishing Venue

The IP.com Prior Art Database


We propose extending revision control tools with an ability to capture implementation-level semantic require dependencies between change sets and keeping track of propagated and removed change sets in forks. This will allow software developers to efficiently maintain forks. More specifically: (1) Discover which change sets are to be propagated together with the change set that they are interested to copy from one fork to another, allowing copying a coherent functionality between forks without breaking the functionality of the software. (2) Determine which dependent change sets will become obsolete when removing a change set from a specific branch, hence can be removed as well. Or in other words, determine the change sets that cannot be removed without removing other functionalities implemented in dependent change sets.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 39% of the total text.

Page 01 of 4

Disclosed is a method that allows efficient management of software forks using semantic require-dependencies between change sets in Software Configuration Management (SCM) systems.

    Revision control (version control, source control) is a practice that tracks and provides control over changes to source code, documentation, configuration files, and other development artifacts. A change set (change list) identifies the set of changes made in a single atomic commit operation. A Branch (stream) is the duplication of an object under revision control (such as a file, or a directory tree) so that modifications can happen in parallel along both branches. Change sets committed to different branches do not interfere with each other, which enables work

isolation and independent development. A history of a branch is a sequence of change sets.

    Branches are generally used for implementing a piece of functionality, a feature, or a software component. In some cases, changes performed in such branches eventually merge into the originating branch. This operation is referred to as synchronization merging : it synchronizes a branch with its ancestor by merging all change sets made to date. In other cases, branches are used to maintain a product portfolio - variants of software targeted for different releases, customers or markets. Such branches, usually called forks , are not intended to be merged. Instead, change sets are selectively propagated between forks (to introduce new functionalities or to fix defects) or removed from them (to exclude functionalities from product variants). Selective change set propagation is accomplished by patching (a.k.a. cherry picking). This technique allows the user to identify and select the exact set of change sets in the source branch to be propagated to the target. Similarly, when

removing functionality, the user is required to manually identify the exact set of change sets to be removed.

This makes the maintenance of forks intensive and error prone: when

selecting change sets for propagation or removal, the developer should manually determine all semantically dependent change sets that need to be propagated or removed together for the software to function properly. Most, if not all, contemporary revision control tools provide no support for that.

Consider the following example:

· Change 1 adds the method A.foo() in class / file A

· Change 2 adds a call to A.foo() in B

· Change 3 adds A.bar() in A.

Temporal dependencies between the change sets, as captured by numerous SCM tools, are shown in Fig. 1(a). This means that change 3 cannot be propagated

without change 2 and change 1 (unless applying patching/cherry picking). Some tools, for example IBM Rational Team Concert (RTC)* take into account files changed in each change set, breaking the temporal dependencies as shown in Fig. 1(b). As the result, they allow propagating change 2 to another stream without propagating changes 1 and 3, which is semantically wrong, b...