CSC/ECE 517 Fall 2009/wiki1a 1 aa

Distributed Version Control

Distributed Version Control (DVC or DVCS) is one way to manage or control revisions of a software package. Unlike the closely related Version Control Systems (VCS), DVC utilizes a peer-to-peer approach rather than a client-server approach.[2] When a developer checks out a project from the main repository, they will have their very own copy or clone of the repository. This allows the developer to commit many revisions to their repository before committing to the main or centralized repository used by the entire development team.

History

Revision control is a vital part of software development. The most widely-used revision control is Version Control Systems such as Subversion or CVS. However, many developers have noticed inadequacies in current VCS tools. Such inadequacies include a need to work disconnected or offline and a desire for increased administrative flexibility. Distributed Version Control overcomes those shortfalls by implementing distributed repositories which are complete with revision history.

Pictorial Overview of Revision Control

Using the idea of making an omelet, this image shows how a team of developers would work on the project using VCS.

Using the same idea of the omelet, this image shows how a team would work on the project using DVC.

Advantages

DVC has several advantages over VCS tools such as Subversion and CVS. Therefore, it is becoming an attractive alternative for revision control. This list summarizes some of the features that DVC includes that VCS does not. However, the list is in no way comprehensive.

1. Developers can work offline being able to view the complete revision history and branches. Commits, rollbacks (restoring code to a previous state), and revision diffs (differences between two revisions) are possible without being connected to a network.[5]

2. Individuals have autonomy as to which revisions are committed to their local repository. The developers do not have to go through a central point of authority before making a change.[1]

3. At any time, a developer can get back to specific individual revisions. This means that if code breaks once the individual revisions have been pushed to the base repository, there is a way to rollback to an individual revision that worked. This is not typically possible when there is one centralized repository.

4. Less time is spent figuring out how to undo a merge that caused code to break. Because of the previously listed advantage, developers can spend more time on functions that are really important rather than playing detective.[5]

5. The base repository remains more settled. Again, because of the two previous advantages, the base repository does not get shaken up as often as a centralized repository in a VCS.[6]

6. Developers using such methods as eXtreme or pair programming can collaborate more freely. It is easy for a small group of developers to pull revisions from others that is specific to one feature without having to get an entire team’s changes for the complete system.[6]

Disadvantages

Just as there are several advantages to using Distributed Version Control, there are also disadvantages or reasons why some developers continue to choose VCS over DVC. Again, this list is in no way comprehensive but does provide a few disadvantages.

1. VCS provides one working version of the software even throughout a maintenance cycle. DVC has many smaller, disjointed working versions, but not a central one. [4]

2. DVC is immature. Therefore, there are many different groups offering many options but with few standards in place. [3]

3. Third party support is not readily available. This is due to the lack of maturity and rapid changes that are currently happening with the DVC products. [3]