This paper presents Tartarian, a tool that supports maintenance of software with long-running, multi-release branches in distributed version control systems. When new maintenance code, such as bug fixes and code improvement, is committed into a branch, it is likely that such code can be applied or reused with some other branches. To do so, a developer may manually identify a commit and cherry pick it. Tartarian can support this activity by providing commit hashtags, which the developer uses as metadata to specify their intentions when committing the code. With these tags, Tartarian uses dependency graph, that represents the dependency constraints of the branches, and Branch Identifier, which matches the commit hashtags with the dependency graph, to identify the applicable branches for the commits. Using Tartarian, developers may be able to maintain software with multiple releases more efficiently.
A presentation of Tartarian is available here.
Starting with describing the Cherry-picking process using DAG of a repository having three releases 1.1, 1.2 and 1.3 where release 1.1 has commit a, release 1.2 has commits a, b and c and release 1.3 has commits a, b, c, d and e. Once the bug fix f is committed to release 1.3, it can be cherry picked to release 1.1 and 1.2 hence release 1.1 becomes a and f, release 1.2 becomes a, b, c and f and release 1.3 becomes a, b, c, d, e and f.
|
* b44ea88 (1.2) Added f (cherry picked from db55fd2) |
As our running example describes the dependencies of Jetty 9.2.x. 9.3.x and 9.4.x release branches, one of which being the dependencies on JDK1.7 (for Jetty 9.2.x) and JDK1.8 (for Jetty 9.3.x and 9.4.x).
|
* a419765 (HEAD -> 9.4.x, master) * d3731d0 (9.3.x) * cc6769f (9.2.x) The DAG of the release 9.2.x, 9.3.x and 9.4.x. |
Next, we will demonstrate a developer committing to release 9.4.x. The commit x makes changes to the code that depends on JDK1.8. For example, the changes in APIs from using the old method \emph{m.getParameterTypes().length} to using a more efficient method introduced in JDK1.8, m.getParameterCount(). This will affect all release branches depending on JDK1.8.
|
* c8836e1 (HEAD -> 9.4.x) changed deprecated method |
Without Tartarian, a developer must manually identify the commits that are applicable for code reuse and make a cherry-picking commit. He usually browses through the issues, related commits and the diff between the versions. Then, he makes decision whether to cherry pick and should the commit can be used as-is or must be modified.
|
$ git cherry-pick c8836e1 |
With Tartarian, developers use hashtag as metadata such as #deprecated to indicate the purpose of this commit and its dependency which effect other release branches. $git tcommit -m "changed deprecated method 132215 #deprecated{JDK, 1.8+}"
|
* c8836e1 (HEAD -> 9.4.x) changed deprecated method x #deprecated{JDK,1.8+} |
Tartarian uses hast tags as constraints on the dependency graph to identify the affected release branches. After a code change is committed to the repository, the Branch Identifier searches through the graph to identify the affected releases. Developers can read the recommendation Tartarian made by using: $git tcommit -r
|
* c8836e1 (9.4.x) change deprecated method |
With this recommendation, developers can make informed decision about the potential commits to be cherry picked and can reuse code more efficiently.
|
* 740dbfa (HEAD -> 9.3.x) cherry picked from c8836e1 |