CSC/ECE 517 Fall 2012/ch1 1w33 op

Comparison of version control system from a programmer’s viewpoint

Introduction

Version control is an aspect of software configuration management. It is a repository of files, usually source codes of computer programs, large web sites that are a part of collective and distributed development. This article compares various version control systems with respect to their features gives the programmer an insight while selecting the best system for his use.

Need of version control

The most critical use of version control is to maintain a backup of all files of the project. From a programmer’s perspective, this will save a lot of rework. Due to version control, all files will be synchronized which will enable all members of the project group to stay updated with all changes related to the project. Version control also keeps track of previous versions of the project for reference. This way a developer can revert to any previous versions of any file in the repository. Documentation of changes in the project is also a part of version control which will help in viewing the evolution of code over a period of time. Features of version control such as sandboxing and branching of code will allow the programmer to work on a code in isolation before broadcasting the updated code.

Types of Version Control Systems

There are three main types of version control system available: local, centralized and distributed .The usage of local version control systems such as RCS is uncommon today and decrepitated.

Local Version Control

Local version control is an early implementation of version control. Local version control stores multiple copies of the same file. The copies are present on only one host machine. Hence all developers have to use the same machine. Here files are managed individually and therefore versioning is possible on files rather than projects. Examples of local version control systems are Revision Control System (RCS) and Source Code Control System (SCCS).

Advantages of local version control

• Local version control is useful when the number of files to be maintained are less and the number of programmers working on it are also few.

Disadvantages of local version control

• Local version control can be implemented on only one workstation. Hence migration of code to other workstations is not possible.
• Versioning of files is done rather than versioning of projects. Therefore it is difficult to track and review changes.

Centralized Version Control

Centralized Version Control works on the basis of client-server model for versioning of project. Here, a working copy of the code is present on the server. The developer has to download this file, make the required changes and the check-in the modified file on the server by committing his code to the repository. He has to ensure that changes done by him are bug free before committing file to the repository.

Advantages of centralized version control

• In centralized version control, the working code is present on a dedicated server. Therefore multiple users can access this code which implies the code can be worked upon from multiple workstations instead of a single workstation.
• Versioning of projects is done in rather than individual versioning of files in centralized version control which will help in tracking and reviewing changes.

Disadvantages of centralized version control

• The developer needs to regularly connect to the server to get the latest code. Therefore working on the code offline is not possible.

Distributed Version Control

Distributed version control uses peer-to-peer model to achieve version control. Here, a centralized canonical version of the code does not exist; rather, the centralized repository is divided into a number of local repositories maintained by each user. The local repositories contain a version of the working code along with the entire history. A developer works upon this code and broadcasts the change in a peer to peer fashion rather than using the client server mode present in centralized version control. If required, a centralized repository of the project can also be created in this system.

Advantages of Distributed version control

• Distributed version control does not require the developer to connect to the network for accessing the repository. Rather, since the developer has the local version of the repository on his workstation itself, he can work on the project offline.
• This system emphasizes on interaction with other developers rather than interaction with a server which is fundamental to any peer-to-peer network.
• It is easier to branch out from the baseline code and this helps in experimentation during development phase.
• It's possible to have multiple central branches for different uses like development, stable, release branches of the same project.
• As this system is not dependent on connection to a central server processes such as committing of code, viewing change log are much simpler.

Disadvantages of Distributed version control

• In many applications it would be advantageous to have a single baseline version of code stored on a server rather than having multiple central versions of the code which can potentially clash with each other later on.
• Having a repository on a dedicated server will augment in faster transfer of code from server to client and vice versa.

Criteria for selecting a particular version control system

• Size of project
• Number of developers working on the project
• Distribution of developers working on the project.
• Technology used for developing
• Plug-ins for IDE’s
• Learning curve
• Speed
• Functionality
• User interfaces (Web and GUI)

Examples of version control systems

• CVS
• Bitkeeper
• Subversion (SVN)
• Monotone
• Perforce
• Git
• Bazaar
• Clearcase
• Mercurial

Selecting a VCS

Selection of a VCS should be based on the need of the project rather than just the pros of that system. The most significant point while classifying a VCS and also while selecting a VCS, is whether the system is server based or peer-to-peer. In a server based system, there is a centralized repository where a file is checked out and checked in with changes. while in a peer to peer based system, the file is frequently updated from peer sources. Below is a comparison of a few version control systems with respect to the above points which may help the programmer selecting a system.

CVS

CVS is one of the earliest version control systems. It has a simple file system for providing the basic functionality of a VCS.It has a client-server model. However it is now obsolete and its functionality is purely reduced to backing up and sharing files. Learning curve: The learning curve for CVS is not too steep.

GUI and IDE

CVS provides a web interface as well as a stand-alone GUI. The plugins for IDE’s are limited with support for only Eclipse, Emacs and Intelij Idea.

Conflict handling

A number of programmers can work on the same file concurrently on their individual working copies of the files and then checking in their modifications. To avoid conflicts, the server only accepts changes made to most recent version of the file. This adds to the overhead of keeping the working copy up-to-date on a regular basis. This task is however automated and requires manual intervention in case of a conflict between the client file and the server file.

Limitations of CVS

• Revisions created by commit are per file rather than containing multiple files.
• Symbolic links and not versioned leading to security risks.
• Unicode and non-ASCII filenames have limited support.
• Commits are not atomic leading to source corruption
• Text files are assumed to be the primary file type stored.
• No support for Distributed revision control.
• Branch operations are expensive since CVS was designed for working on a trunk.

Bazaar

Bazaar is a free distributed VCS written in python with packages for Linux, Windows and Mac OS. Distributed as well as Central: Bazaar can be used in either a distributed workflow style or with a more standard centralized version control style. Bazaar also works well for single user project in a way that you don’t have to create your own repository and check out a working copy. You work from your project directory and Bazaar does the tracking from there. Work offline: The distributed nature allows you to work with without a net connection. This can be achieved with the centralized version control by having a local repository.

Merging

Bazaar’s merging supports merging multiple branches with a single requirement that the branches have a common ancestor. It also provides a feature called ‘cherrypicking’ wherein you can merge only some changes of a branch. You can also shelve changes that you are working on. This is useful when you are working on multiple patches.

GUI and IDE

For a web interface, Bazaar uses a plain webserver. It also has stand alone GUI’s Bazaar explorer, TortoiseBzr. Bazaar provides plugins for Eclipse, TextMate, Visual Studio and Komodo IDE.

Learning curve

Since it is one of the most feature heavy system, it is a slightly complicated.

Limitations

It is more complicated to backup repositories. Either all the projects need to be kept in one main directory as sub directories or we need to make sure that all directories are being backed up.

Mercurial

Mercurial is a distributed cross platform version control system implemented in Python. Mercurial’s major design goals are scalability, high performance, robust handling of bin and plain text files, advanced branching and merging capabilities. In spite of all these advances features, mercurial remains conceptually simple.

Learning curve:

Mercurial is similar to SVN and hence for those already familiar with SVN, the learning curve will be less steep. The documentation of mercurial is more complete which facilitates faster learning.

GUI and IDE

Mercurial is primarily command line based but graphical extensions are available. Bitbucket, Trac are the web interfaces and TortoiseHg, MacHg, SourceTree are the standalone GUI’s. It provides plugins for IntelliJ IDEA, Eclipse, NetBeans, Visual Studio, Emacs, Vim (VCSCommand plugin), Komodo IDE.

Merging

Mercurial uses a 3-way merge algorithm.

Limitations:

• It does not allow merging of two parents.
• Extension based rather than being scriptable that may be ideal for some programmers
• Less out of box power.

SVN

SVN is a successor of CVS fixing most if its problems. Atomic operations (either the change is fully committed or it is not committed at all) are included. Branch operations are easier and cheaper.

Tagged Commits

Tagging means labeling a repository at any point of time so that it will be easier to find it in the future. It is a neat way of maintain extra data about your files.

Merging/Conflict Resolution:

A conflict has to be explicitly marked as resolved before being committed. This reduces the chances of a conflict being accidently committed. Merging multiple branches or cross-merging between branches is difficult due to the client-server model.

IDE and GUI

Unlike CVS, SVN has provided plugins for a number of IDE’s like Eclipse, NetBeans, Visual Studio, Intellij Idea, TextMate, Rabbit, Komodo, BBEdit, Emacs. It also has WebSvn ,Trac as web interfaces and Nautilus, Qt, RabbitVCS, RapidSVN, SourceTree as standalone GUI’s. Limitations:

• Does not use peer-to-peer model
• Contains bugs relating to renaming files and directories.
• Insufficient repository management commands.
• Slower that bazaar and Git.

Git

Git is a distributed revision control system that takes a radical approach different from the traditional ones. Its original concept makes it the fastest distributed VCS. Git supports non-linear development process meaning that changes will be repeatedly merged as the code is reviewed or the requirements change. Thus Git is most suited for agile development. The purpose of Git was to be fast and scalable and it does that very successfully

Merging

• The traditional 3-way merge algorithm.
• Recursive approach when pulling or merging one branch
• Octopus is used when merging two heads.

Compatibility:

Git works with SVN meaning you can use a subversion directory directly with Git.

Security

The history is stored in such a way that the name of a revision depends on the history to that point. Once the revision is published, it can't be changed without the change being visible. The revisions are identified with SHA 1 ID’s.

Tags

Tags are extremely powerful. Any arbitrary description can be attached to the tag.

IDE’s and GUI

Git has a web interface GitHub, standalone GUI’s Gitbox, Tortoise, Smart Git. It has plugins for a number of IDE’s Aptana 3 Beta (Aptana Studio 3 with Git Integration); Eclipse (JGit/EGit); Netbeans (NbGit); KDevelop; Visual Studio (Git Extensions); Emacs (extension for standard VC); TextMate (Git TextMate Bundle); Vim (VCSCommand plugin and fugitive plugin); IntelliJ IDEA >8.1 (standard in Community and Ultimate Editions); Komodo IDE; Anjuta.

Limitations

• Learning curve is a little steep.
• Not optimal for single developers.
• Limited windows support as compared to linux.

References

<references/>

• 1. CVS
• 2. Bazaar
• 3. Mercurial
• 4. SVN
• 5. Git

See also

• Version Control Basics
• Which VCS is best for you
• Wikipedia Revision Control
• Comparison of Git, Mercurial and CVS
• Comparison on various VCS