Background: Revision control is the management of multiple versions of the same information and is nowadays seen as a must for all but the most simple software development projects. There are many revision control systems in use, all with their respective strengths and weaknesses.
There are two main approaches used by revision control systems: the centralized approach and the distributed approach.
In the centralized approach all revisions are stored in a central repository that the developers somehow access, in some of these systems the developer makes a check-out of all the files in the repository and in others the developer works directly towards the repository server. Some of the more well-known centralized revision control systems are CVS, Subversion, Perforce and Rational Clearcase.
In the distributed approach all developers have local repositories and they can propagate changes between their respective repositories. Distributed revision control systems include BitKeeper, GNU Arch and Bazaar.
Many organizations use a workflow for development consisting of branching and merging. Different organizations do this in different ways, so we're going to present two standard use-cases:
1. One branch is used for all development. When it's getting close to a release the codeline is frozen, that is no new functionality is accepted into the codeline, and the main branch is only used for bugfixing until the release. In order to not have to cease all development of new features a new development branch is created and all the new features are added to this codeline. But since the bugfixes in the main codeline also are needed in the development branch, changes from the main codeline need to be merged into the development codeline. When the software is released the development branch becomes the new main branch.
2. Another branch is used and this branch is always stable. When a developer wants to work on a new feature he/she creates a feature branch from this codeline and works exclusively on the feature branch. Periodically the developer needs to merge in new changes (that are presumed to be stable) from the main codeline to keep in sync with it and at the end of the development of the new feature the feature branch is merged back into the main branch.
Merge tracking is the ability of the revision control software to be able to automatically keep history of what merges have happened and when. That is if we for example have a main branch A and a developer creates a feature branch B we might have the following scenario:
- B is branched off from A.
- Development is ongoing in A.
- The developer does a lot of changes to B.
- Changes from A are merged into B.
- More changes are made to both A and B.
- Changes from A are merged into B again (here the changes merged in step 3 cannot be merged again).
- B is merged back into A.
In many revision control systems, this scenario presents no problem. For example Rational Clearcase stores information about each branch and merge using so called hyperlink. The distributed revision control systems are also traditionally very good at this kind of work, since conceptually each developers working copy is a branch in its own.
Problem statement: Subversion, nowadays seen as the de-facto successor to CVS, does currently not have merge-tracking functionality (and neither has CVS). This means that a developer has to do a lot of manual book-keeping to be able to do branching and merging in a good way, this most often leads to a workflow where branching and merging are avoided in most cases, and thus usage scenarios two and three are not really feasible to use with these systems. The problem addressed in this thesis is thus how to implement merge-tracking.
Objective: The thesis work has these objectives:
- Study different approaches to merge-tracking and evaluate their respective pros and cons. Here it is recommended that the student studies different revision control systems and their implementations.
- Write an implementation of merge-tracking for Subversion.
- Submit this implementation to the Subversion community, for possible future inclusion in the official Subversion codebase.
References
General information
Existing revision control systems
-
-
CVS (no merge tracking support)
-
-
-
Bazaar (merge tracking support)
-
-
Other resources
-
Svnmerge (a rudimentary implementation of merge tracking using Subversion attributes)
Prerequisite: We're looking for a dedicated student with theoretical understanding of Computer Science and solid programming skills, preferably someone with experience from Open-Source projects.