CSC/ECE 517 Fall 2011/ch1 1f rs

Introduction

Version control also called Sub-Version Control and Revision Control helps large projects from spinning out of control by letting different programmers, each handle a project from a different angle without getting in each other’s way and without doing damage that cannot be undone.

Some of the most popular version control systems are RCS, SVN, CVS, Mercurial and Git. This article intends to compare these version control systems in a programmer’s viewpoint.

Which version control system is the best suited for programmers?

There are a number of solutions out there, and we have put together a definitive feature comparison for reference on deciding about the best choice.

The main difference between Version Control Systems is whether they are server based or peer to peer based. Either they have a centralized repository where code is checked out and back in with changes, or a setup where the code is frequently updated from peer sources, a more decentralized network to keep your code current.

The article further compares all the Version Control Systems like RCS, CVS and Distributed Version Control Systems. Also, the article compares multiple Version Control applications like Mercurial, Git, Clearcase and CVS. Comparison is done in the view of programmer. Various commands used in different applications are discussed.

Comparison of Version Control Applications

Overview of Version Control Applications

RCS: The Revision Control System (RCS)

RCS manages multiple revisions of files. RCS automates the storing, retrieval, logging, identification, and merging of revisions. RCS is useful for text that is revised frequently, including source code, programs, documentation, graphics, papers, and form letters. This is the most basic and most primitive Version Control System known to programmers.

CVS: The Concurrent Versions System (CVS)

CVS is a client-server free software revision control system in the field of software development. Version control system software keeps track of all work and all changes in a set of files, and allows several developers (potentially widely separated in space and/or time) to collaborate.The CVS server runs on Unix-like systems with client software that runs on multiple operating systems. It is considered the most mature version control system because it has been developed for such a long time and does not receive many requests for new features at this time. A fork project of CVS, CVSNT was created to run CVS on Windows servers, and it is currently being actively developed to increase functionality.

More information about CVS can be found in this site: CVS

SVN: Sub Version (SVN)

SVN was created as an alternative to CVS that would fix some bugs in the CVS system while maintaining high compatibility with it. Like CVS, SVN is free and open source with the difference of being distributed under the Apache license as opposed to GNU. To prevent corruption in the database from being corrupted, SVN employs a concept called atomic operations. Either all of the changes made to the source are applied or none are applied, meaning that no partial changes will break the original source.Many developers have switched to SVN as it is a newer technology that takes the best features of CVS and improves upon them. While CVS’s branch operations are expensive and do not really lend themselves to long-term forks in the project, SVN is designed to allow for it, lending itself better to large, forked projects with many directions.Criticism of SVN includes slower comparative speed and the lack of distributed revision control. Distributed revision control uses a peer-to-peer model rather than using a centralized server to store code updates. While a peer-to-peer model would work better for world-wide, open source projects, it may not be ideal in other situations. The downside to a dedicated server approach is that when the server is down, no clients are able to access the code.

More information about SVN can be found in this site: SVN

Git:

Git takes a radical approach that differs greatly from CVS and SVN. The original concepts for Git were to make a faster, distributed revision control system that would openly defy conventions and practices used in CVS. It is primarily developed for Linux and has the highest speeds on there. It will also run on other Unix-like systems, and native ports of Git are available for Windows as msysgit. As there is no centralized server, Git does not lend itself to single developer projects or small teams as the code may not necessarily be available when using a non-repository computer. Workarounds exist for this problem, and some see Git’s improved speed as a decent tradeoff for the hassle.

More information about Git can be found in this site: Git

Mercurial:

Mercurial began close to the same time as Git and is also a distributed revision control tool. It was originally made to compete with Git for Linux kernel development. It’s different from other revision control systems in that Mecurial is primarily implemented in Python as opposed to C, but there are some instances where C is used.Users have noted that Mecurial shares some features with SVN as well as being a distributed system, and because of the similarities, the learning curve for those already familiar with SVN will be less steep. The documentation for Mecurial also is more complete and will facilitate learning the differences faster. Some of the major drawbacks to Mecurial include that it doesn’t allow for two parents to be merged and unlike Git, it uses an extension system rather than being scriptable. That may be ideal for some programmers, but many find the power of Git to be a feature they don’t want to trade off.

More information about Mercurial can be found in this site: Mercurial

Basic Features

---

Software	Repository model	Concurrency model	Programming Languages	Scope of Change	Atomic commits	File Renames	Interactive Commits	Partial Checkout/clone	Platforms supported
RCS	Set of files	Merge	C	File	No	No	No	Yes	Java Platforms (Unix-like, Microsoft Windows|Windows, Mac OS X)
CVS	Client-Server	Merge	C	File	No	No	No	Yes	Java Platforms (Unix-like, Microsoft Windows|Windows, Mac OS X)
SVN	Client-Server	Merge or Lock	C	Tree	Yes	Yes	No	Yes	Java Platforms (Unix-like, Microsoft Windows|Windows, Mac OS X)
Clear Case	Client-Server	Merge or Lock	C, Java, Perl	File	Partial	Yes	No	Yes	Java Platforms (Unix-like, Microsoft Windows|Windows, Mac OS X)
Git	Distributed	Merge	C,Perl	Tree	Yes	Partial	Yes	No	Java Platforms (Unix-like, Microsoft Windows|Windows, Mac OS X)
Mercurial	Distributed	Merge	Python, C	Tree	Yes	Yes	Yes	No	Java Platforms (Unix-like, Microsoft Windows|Windows, Mac OS X)

Feature	Feature Description
Repository Model	Describes the relationship between various copies of the source code repository.
Concurrency Model	Describes how changes to the working copy are managed to prevent simultaneous edits from causing nonsensical data in the repository.
Programming Languages	The coding language in which the application is being developed
Scope of Change	Describes whether changes are recorded for individual files or for entire directory trees.
Atomic commits	Refers to a guarantee that all changes made are merged, or that no change at all will be made.
File Renames	Describes whether a system allows files to be renamed while retaining their version history.
Interactive Commits	Interactive commits allow the user to cherrypick the patch-hunks that become part of a commit, instead of having only a file-level granularity.
Partial Checkout/clone	Ability to check out or clone only a specified subdirectory from a repository.

Basic Commands

---

Software	Clone	Pull	Push	Checkout	Add	Remove	Merge	Commit	Revert	Rebase
RCS	Not Supported	Not Supported	Not Supported	co	Not Supported	rcsclean	rcsmerge	ci	Not Supported	Not Supported
CVS	Not Supported	Not Supported	Not Supported	checkout	add	rm	update -j	commit	rm, update	Not Supported
SVN	svnadmin hotcopy	svnadmin load	svnadmin dump	checkout	add	rm	merge	commit	revert	Not Supported
Clearcase	Not Supported	Not Supported	Not Supported	checkout	mkelem	rmelem	merge	checkin	unco/rmver	findmerge
Git	Clone	Fetch	Push	Clone	add	rm	merge	commit	checkout	rebase
Mercurial	Clone	Pull	Push	Clone	add	rm	merge	commit	revert	rebase

Command	Command Description
Clone	Create an identical instance of a repository
Pull	Download revisions from a remote repository to a local repository
Push	Upload revisions from a local repository to a remote repository
Checkout	Create a local working copy from a (remote) repository
Add an element	Mark specified files to be added to repository at next commit
Remove an element	Mark specified files to be removed at next commit
Merge	Apply the differences between two sources to a working copy path
Commmit	Record changes in the repository
Checkout	Restore working copy file from repository
Rebase	Forward-port local commits to the updated upstream head