CSC/ECE 517 Fall 2011/ch1 1f rs: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
No edit summary
 
(122 intermediate revisions by 2 users not shown)
Line 1: Line 1:
=='''Comparing version-control systems from the programmer's standpoint:'''==
=='''Comparison of Version Control Systems : The Programmer View'''==
 
 
__TOC__


== Introduction ==
== 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.
Version control or Revision Control is indispensable in large projects. They make sure that projects are not spinning out of control by letting different programmers work on the project from a different perspective without getting in each other’s way and without doing any damage that cannot be undone.
 
The article compares all the Version Control Systems like RCS, CVS and Distributed Version Control Systems from a developer's point of view.It further extends the comparison to popular version control applications like RCS, SVN, CVS, Clearcase, Mercurial and Git.
 
== Comparison of Version Control Systems==
[[Image:RCS.png|thumb|150px|alt=Local Version Control]]
==== Local Version Control ====
This is a primitive approach of version control. The system operates on single files only.<ref>http://en.wikipedia.org/wiki/Revision_Control_System</ref> It has no way of working with an entire project. Changes to a file are stored as 'deltas' with the aid of a diff utility. Since the approach maintain many copies of files, it is generally cumbersome with reduced efficiency.
 
 
[[Image:CVS.png|thumb|150px|alt=Centralized Version Control]]
 
==== Centralized Version Control ====
CVS implements a Client-Server model to achieve version control. A central repository is maintained which is used by all the developers of a project. Programmers can only have a working copy of the project. The model allows a developer to checkout only the required files or branches. In this model all operations on the code (commit, exchange of code etc.)  involve communication with the central server via a network. This means that these operations are not available when the user is offline. Also  issues in communication with the server may disrupt the development activity.
Any changes to the project on the server involves an authentication process. Hence only users with certain privileges can commit code on the central server . A developer can checkpoint or create branches on his work only by committing his changes to the central repository.  Since all the developers commit changes on the same repository, it is generally challenging to resolve conflicts when merging or reconciling changes from other branches.
 
 
 
 
==== Distributed Version Control ====
[[Image:File-DVCS.png|thumb|150px|alt=Distributed Version Control]]
This system implements a peer to peer model to achieve version control. No reference copy of the codebase exist by default. However in practice, an official reference copy is indeed maintained. The model  requires the developers to possess a full blown backup of the repository , including the entire history. As a result, the developers can collaborate directly without the need of a central authority. Hence it allows developers to be productive even when offline. (e.g. when travelling). Also the overhead of communicating with a central repository is overcome in this approach.
Branching and merging fit much better in this approach as each user has his own branch. The administrator's major work is to merge appropriate changes from branches of different users. This is relatively simpler compared to  the centralized system. As a result, the distributed system scales much better with the number of people.
 
==== Summary of Centralized versus Distributed Approach ====
 
{| class="wikitable" style="font-size: 100%; text-align: center; width: auto;"
|-
! Centralized Version Control
! Distributed Version Control
|-
| Client - server model
| peer- to -peer model
|-
| Single central repository.
| Multiple repositories
|-
| Changes can be committed only Online
| Changes can be committed offline
|-
| Allows developer to checkout required files/branches.
| Complete repository has to be downloaded by the programmer
|-
| Merging and Branching operations are complicated as
multiple programmers work on the same repository at the same time.
| Branching is simple as each programmer gets a branch
|-
| Repository maintenance becomes more challenging with number of people
| Scales better with number of people
|}
 
== Comparison of Version Control Applications ==
==== Overview of Version Control Applications ====
 
=====  RCS: The Revision Control System (RCS)=====
 
RCS manages multiple revisions of files. RCS operates on a set of files. RCS automates the process of storing, retrieval, logging, identification, and merging of multiple revisions. It is useful for text that is modified frequently which includes source code, programs, documentation, graphics, papers, and letters. This is the most basic and most primitive Version Control System known to programmers.
 
More information about RCS can be found at [http://www.gnu.org/s/rcs/ RCS]
 
===== ClearCase: =====
 
ClearCase is a comprehensive software configuration management system. It is used to manage multiple versions of evolving software systems, tracks which versions were used in software builds, used to perform builds of individual programs or complete releases according to user-defined version and system specifications.
 
These capabilities enable ClearCase to address the issues and critical requirements of organizations that develop software:
 
Effective development — ClearCase enables users to work efficiently, allowing them to fine-tune the balance between sharing each other's work and isolating themselves from destabilizing changes done. ClearCase automatically manages the sharing of both source files and the files produced by software builds.
 
Effective management — ClearCase tracks the software build process, so that users can determine what was built, and how it was built. Further, ClearCase can instantly recreate the source base from which a software system was built, allowing it to be rebuilt, debugged, and updated — all without interfering with other programming work.
 
Enforcement of development policies — ClearCase enables project administrators to define development policies and procedures, and to automate their enforcement.
 
More information about ClearCase can be found at [http://www-01.ibm.com/software/awdtools/clearcase/ ClearCase]
 
=====  CVS: The Concurrent Versions System (CVS)=====
 
CVS is a Client-Server software revision control system in the field of software development. Version control software keeps track of all the changes in a set of files, and makes sure that several developers (potentially widely separated in space and/or time) can collaborate in real time. The CVS server runs on Unix-like systems with client software that runs on different operating systems on multiple client machines. It is regarded as the most mature version control system because it has been developed for such a long time and has stood the test of 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 and make it more usable on Windows platform.
 
More information about CVS can be found at [http://www.nongnu.org/cvs/ CVS]
 
=====  SVN: Sub Version (SVN)=====
 
SVN was created as an alternative to CVS that would be useful to fix some known issues in CVS and also maintaining high compatibility with it. SVN is free and open source with the difference of being distributed under the Apache license as opposed to GNU which distributes licenses for CVS. To prevent the database from being corrupted, SVN adopts a technique called 'Atomic Operations'. Either all of the modifications made to the source are committed or none are committed. Partial changes will not enter the original source. Many developers have switched to SVN as it is a newer technology that starts with the best features of CVS and improves upon them. While branch operations in CVS are expensive and do not really lend themselves to long-term forks in the project, SVN is designed to allow for it. Hence it lends itself better to large forked projects with many directions. Some known disadvantages of SVN includes slower operation speeds and the lack of distributed revision control. Distributed revision control uses a peer-to-peer model as compared to using a centralized server to store code modifications. Peer-to-peer model work better for open source projects which are spread over multiple far away physical locations. The downside to a dedicated server approach is the issue of not having redundancy in the case when the server is down leading to no access to clients.


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.
More information about SVN can be found at [http://subversion.apache.org/ SVN]


=====  Git:=====


== Which version control system is the best suited for programmers? ==
Git takes a totally diverse approach that differs greatly in comparison to CVS and SVN. The original concepts for Git were to make a faster, distributed version control system that would openly invalidate 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 Windows agents are known as msysgit. As there is no centralized server, Git is not very suitable for single developer projects or small teams as the code may not necessarily be available when using a normal computer. Workarounds exist for this problem. Developers look out for Git’s improved speed as a decent trade off for the hassle.
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.
More information about Git can be found at [http://git-scm.com/ Git]


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.
=====  Mercurial:=====


== A brief Description about the Version Control Systems being compared: ==
Mercurial is a distributed revision control tool which began close to the same time as Git. Mercurial was originally made to compete with Git for Linux kernel development. Mercurial is primarily implemented in Python as opposed to C, but there are some instances where C is used. This is a major difference compared to other version control systems in Developer's point of view. Users feel that Mercurial is similar to SVN with respect to certain features, as well as being a distributed system. This acts as an advantage for the tool as the learning curve for those already familiar with SVN will be less steep. The documentation for Mercurial is very well compiled and facilitates understanding the differences faster. One of the major drawback to Mercurial is that it does not allow for two parents to be merged. Unlike Git, it uses an extension system rather than using scripts. That may be ideal for some section of programmers, but many find the speed of operation of Git to be a feature they do not want to trade off for anything.


1. '''''RCS: The Revision Control System (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.
More information about Mercurial can be found at [http://mercurial.selenic.com Mercurial]


More information about RCS can be found in this site: [http://www.cs.purdue.edu/homes/trinkle/RCS/ RCS]
==== Basic Features ====
------------------------------------------------------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------------------------------------------------------


{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Repository model|Repository model
! #Concurrency model|Concurrency model
! #Programming Languages|Programming Languages
! #Scope of Change|Scope of Change
! #Atomic commits|Atomic commits
! #File Renames|File Renames
! #Interactive Commits|Interactive Commits
! #Partial Checkout/clone|Partial Checkout/clone
! Platforms supported
|-
! RCS
| Set of files
| Merge
|  C
|  File
|  No
|  No
|  No
|  Yes
| Unix-like
|-
! CVS
| Client-Server
| Merge
|  C
|  File
|  No
|  No
|  No
|  Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! SVN
| Client-Server
| Merge or Lock
|  C
|  Tree
|  Yes
|  Yes
|  No
|  Yes
| Unix-like, Microsoft Windows|Windows, Mac OS X
|-
! Clear Case
| Client-Server
| Merge or Lock
|  C, Java, Perl
|  File
|  Partial
|  Yes
|  No
|  Yes
| Linux, Windows, AIX, Solaris, HP UX, i5/OS, OS/390, z/OS
|-
! Git
| Distributed
| Merge
|  C,Perl
|  Tree
|  Yes
|  Partial
|  Yes
|  No
| POSIX, Windows, Mac OS X
|-
! Mercurial
| Distributed
| Merge
|  Python, C
|  Tree
|  Yes
|  Yes
|  Yes
|  No
| Unix-like, Microsoft Windows|Windows, Mac OS X
|}


2.'''''CVS: The Concurrent Versions System (CVS)''''', also known as the Concurrent Versioning System, 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.
{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! 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.
|}


More information about CVS can be found in this site: [http://www.nongnu.org/cvs/  CVS]
==== Basic Commands ====
------------------------------------------------------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------------------------------------------------------


3. '''''SVN: Sub Version (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.
{| class="wikitable sortable" style="font-size: 95%; text-align: center; width: auto;"
|-
! Software
! #Clone|Clone
! #Pull|Pull
! #Push|Push
! #Checkout|Checkout
! #Add|Add
! #Remove|Remove
! #Merge|Merge
! #Commit|Commit
! #Revert|Revert
! #Rebase|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
|}
 
 
{| class="wikitable sortable" style="font-size: 95%; text-align: left; width: auto;"
|-
! 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
|-
! Commit
| Record changes in the repository
|-
! Checkout
| Restore working copy file from repository
|-
! Rebase
| Forward-port local commits to the updated upstream head
|}
 
== Sample Workflow involving Clearcase ==
 
This section provides an example of a sample workflow used by a programmer to maintain the code in Clearcase.<ref>http://www.ibm.com/developerworks/rational/library/836.html</ref>


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.
Command to create a new view:
<pre>cleartool mkview -tag atag  storage-location </pre>


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.
Command to create a new file:
<pre>cleartool mkelem <file_name></pre>


More information about SVN can be found in this site: [http://subversion.apache.org/ SVN]
Command to create a new branch:
------------------------------------------------------------------------------------------------------------------------------------------------
<pre>cleartool mkbranch -nc <version_selector></pre>
 
Command to checkout a file for editing:
<pre>cleartool co -nc <file_name></pre>
 
Command to check in a file after editing:  
<pre>cleartool ci -nc <file_name></pre>
 
Command to check the current working view:
<pre>ct pwv</pre>
 
Command to view/edit the current config spec for the view:
<pre>ct catcs /edcs</pre>
 
Command to merge and deliver the code changes:
<pre>cleartool merge -to target-path -insert contributor-version-selector <name_version></pre>
 
Command to delete a file:
<pre>cleartool rmelem <file_name></pre>
 
Command to delete a view:
<pre>cleartool rmview <view_name></pre>
 
== Choice of Version Control ==
The choice of version control systems depends on the developers and the projects. Teams use CVS because they are already used to it and have found ways to overcome its limitation. The project would continue to deploy CVS if the prospect of migrating to another revision control is cumbersome.SVN is more commonly used in the corporate world which believes that a single server technology would ease the transitions related to the project.Also, since SVN is highly matured, any help is readily available for the users.Distributed Systems like Git is more preferred for a open source project where several programmers work at different times and provide several updates to the code.
 
Hence Version Control systems have to be chosen based on the requirements of the project and its team.
 
==References==
<references/>


4.''''' 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.
==See also==
* [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch1_1a_br Information about Version Control Systems]


More information about Git can be found in this site: [http://git-scm.com/ Git]
* [http://excess.org/article/2008/07/ogre-git-tutorial/ A Video presentation on "Git, The Basics"]
------------------------------------------------------------------------------------------------------------------------------------------------


5.'''''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.
* [http://www.youtube.com/watch?v=4XpnKHJAok8 Linus Torvals on Git]


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.
* [http://changelog.complete.org/archives/698-if-version-control-systems-were-airlines If version control systems were airlines]


More information about Mercurial can be found in this site: [http://mercurial.selenic.com/ Mercurial]
==External links==
------------------------------------------------------------------------------------------------------------------------------------------------
* [http://code.google.com/p/support/wiki/DVCSAnalysis Comparison between Git and Mercurial] by Google (summer 2008)
* [http://www.softeng.rl.ac.uk/media/uploads/publications/2010/03/cvs-svn.pdf Comparison of CVS and Subversion]
* [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software Revision Control Systems Comparison]
* [http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.tutorial.doc/a_wflow_cc_proj.htm IBM Software Information Center]
* [http://schacon.github.com/git/gittutorial.html Git Tutorial]
* [http://www.szakmeister.net/blog/2011/feb/17/choosing-new-version-control-system/ Choosing a Version Control System]

Latest revision as of 00:38, 26 September 2011

Comparison of Version Control Systems : The Programmer View

Introduction

Version control or Revision Control is indispensable in large projects. They make sure that projects are not spinning out of control by letting different programmers work on the project from a different perspective without getting in each other’s way and without doing any damage that cannot be undone.

The article compares all the Version Control Systems like RCS, CVS and Distributed Version Control Systems from a developer's point of view.It further extends the comparison to popular version control applications like RCS, SVN, CVS, Clearcase, Mercurial and Git.

Comparison of Version Control Systems

Local Version Control

Local Version Control

This is a primitive approach of version control. The system operates on single files only.<ref>http://en.wikipedia.org/wiki/Revision_Control_System</ref> It has no way of working with an entire project. Changes to a file are stored as 'deltas' with the aid of a diff utility. Since the approach maintain many copies of files, it is generally cumbersome with reduced efficiency.


Centralized Version Control

Centralized Version Control

CVS implements a Client-Server model to achieve version control. A central repository is maintained which is used by all the developers of a project. Programmers can only have a working copy of the project. The model allows a developer to checkout only the required files or branches. In this model all operations on the code (commit, exchange of code etc.) involve communication with the central server via a network. This means that these operations are not available when the user is offline. Also issues in communication with the server may disrupt the development activity. Any changes to the project on the server involves an authentication process. Hence only users with certain privileges can commit code on the central server . A developer can checkpoint or create branches on his work only by committing his changes to the central repository. Since all the developers commit changes on the same repository, it is generally challenging to resolve conflicts when merging or reconciling changes from other branches.



Distributed Version Control

Distributed Version Control

This system implements a peer to peer model to achieve version control. No reference copy of the codebase exist by default. However in practice, an official reference copy is indeed maintained. The model requires the developers to possess a full blown backup of the repository , including the entire history. As a result, the developers can collaborate directly without the need of a central authority. Hence it allows developers to be productive even when offline. (e.g. when travelling). Also the overhead of communicating with a central repository is overcome in this approach. Branching and merging fit much better in this approach as each user has his own branch. The administrator's major work is to merge appropriate changes from branches of different users. This is relatively simpler compared to the centralized system. As a result, the distributed system scales much better with the number of people.

Summary of Centralized versus Distributed Approach

Centralized Version Control Distributed Version Control
Client - server model peer- to -peer model
Single central repository. Multiple repositories
Changes can be committed only Online Changes can be committed offline
Allows developer to checkout required files/branches. Complete repository has to be downloaded by the programmer
Merging and Branching operations are complicated as

multiple programmers work on the same repository at the same time.

Branching is simple as each programmer gets a branch
Repository maintenance becomes more challenging with number of people Scales better with number of people

Comparison of Version Control Applications

Overview of Version Control Applications

RCS: The Revision Control System (RCS)

RCS manages multiple revisions of files. RCS operates on a set of files. RCS automates the process of storing, retrieval, logging, identification, and merging of multiple revisions. It is useful for text that is modified frequently which includes source code, programs, documentation, graphics, papers, and letters. This is the most basic and most primitive Version Control System known to programmers.

More information about RCS can be found at RCS

ClearCase:

ClearCase is a comprehensive software configuration management system. It is used to manage multiple versions of evolving software systems, tracks which versions were used in software builds, used to perform builds of individual programs or complete releases according to user-defined version and system specifications.

These capabilities enable ClearCase to address the issues and critical requirements of organizations that develop software:

Effective development — ClearCase enables users to work efficiently, allowing them to fine-tune the balance between sharing each other's work and isolating themselves from destabilizing changes done. ClearCase automatically manages the sharing of both source files and the files produced by software builds.

Effective management — ClearCase tracks the software build process, so that users can determine what was built, and how it was built. Further, ClearCase can instantly recreate the source base from which a software system was built, allowing it to be rebuilt, debugged, and updated — all without interfering with other programming work.

Enforcement of development policies — ClearCase enables project administrators to define development policies and procedures, and to automate their enforcement.

More information about ClearCase can be found at ClearCase

CVS: The Concurrent Versions System (CVS)

CVS is a Client-Server software revision control system in the field of software development. Version control software keeps track of all the changes in a set of files, and makes sure that several developers (potentially widely separated in space and/or time) can collaborate in real time. The CVS server runs on Unix-like systems with client software that runs on different operating systems on multiple client machines. It is regarded as the most mature version control system because it has been developed for such a long time and has stood the test of 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 and make it more usable on Windows platform.

More information about CVS can be found at CVS

SVN: Sub Version (SVN)

SVN was created as an alternative to CVS that would be useful to fix some known issues in CVS and also maintaining high compatibility with it. SVN is free and open source with the difference of being distributed under the Apache license as opposed to GNU which distributes licenses for CVS. To prevent the database from being corrupted, SVN adopts a technique called 'Atomic Operations'. Either all of the modifications made to the source are committed or none are committed. Partial changes will not enter the original source. Many developers have switched to SVN as it is a newer technology that starts with the best features of CVS and improves upon them. While branch operations in CVS are expensive and do not really lend themselves to long-term forks in the project, SVN is designed to allow for it. Hence it lends itself better to large forked projects with many directions. Some known disadvantages of SVN includes slower operation speeds and the lack of distributed revision control. Distributed revision control uses a peer-to-peer model as compared to using a centralized server to store code modifications. Peer-to-peer model work better for open source projects which are spread over multiple far away physical locations. The downside to a dedicated server approach is the issue of not having redundancy in the case when the server is down leading to no access to clients.

More information about SVN can be found at SVN

Git:

Git takes a totally diverse approach that differs greatly in comparison to CVS and SVN. The original concepts for Git were to make a faster, distributed version control system that would openly invalidate 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 Windows agents are known as msysgit. As there is no centralized server, Git is not very suitable for single developer projects or small teams as the code may not necessarily be available when using a normal computer. Workarounds exist for this problem. Developers look out for Git’s improved speed as a decent trade off for the hassle.

More information about Git can be found at Git

Mercurial:

Mercurial is a distributed revision control tool which began close to the same time as Git. Mercurial was originally made to compete with Git for Linux kernel development. Mercurial is primarily implemented in Python as opposed to C, but there are some instances where C is used. This is a major difference compared to other version control systems in Developer's point of view. Users feel that Mercurial is similar to SVN with respect to certain features, as well as being a distributed system. This acts as an advantage for the tool as the learning curve for those already familiar with SVN will be less steep. The documentation for Mercurial is very well compiled and facilitates understanding the differences faster. One of the major drawback to Mercurial is that it does not allow for two parents to be merged. Unlike Git, it uses an extension system rather than using scripts. That may be ideal for some section of programmers, but many find the speed of operation of Git to be a feature they do not want to trade off for anything.

More information about Mercurial can be found at 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 Unix-like
CVS Client-Server Merge C File No No No Yes Windows, Mac OS X
SVN Client-Server Merge or Lock C Tree Yes Yes No Yes Windows, Mac OS X
Clear Case Client-Server Merge or Lock C, Java, Perl File Partial Yes No Yes Linux, Windows, AIX, Solaris, HP UX, i5/OS, OS/390, z/OS
Git Distributed Merge C,Perl Tree Yes Partial Yes No POSIX, Windows, Mac OS X
Mercurial Distributed Merge Python, C Tree Yes Yes Yes No 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
Commit Record changes in the repository
Checkout Restore working copy file from repository
Rebase Forward-port local commits to the updated upstream head

Sample Workflow involving Clearcase

This section provides an example of a sample workflow used by a programmer to maintain the code in Clearcase.<ref>http://www.ibm.com/developerworks/rational/library/836.html</ref>

Command to create a new view:

cleartool mkview -tag atag  storage-location 

Command to create a new file:

cleartool mkelem <file_name>

Command to create a new branch:

cleartool mkbranch -nc <version_selector>

Command to checkout a file for editing:

cleartool co -nc <file_name>

Command to check in a file after editing:

cleartool ci -nc <file_name>

Command to check the current working view:

ct pwv

Command to view/edit the current config spec for the view:

ct catcs /edcs

Command to merge and deliver the code changes:

cleartool merge -to target-path -insert contributor-version-selector <name_version>

Command to delete a file:

cleartool rmelem <file_name>

Command to delete a view:

cleartool rmview <view_name>

Choice of Version Control

The choice of version control systems depends on the developers and the projects. Teams use CVS because they are already used to it and have found ways to overcome its limitation. The project would continue to deploy CVS if the prospect of migrating to another revision control is cumbersome.SVN is more commonly used in the corporate world which believes that a single server technology would ease the transitions related to the project.Also, since SVN is highly matured, any help is readily available for the users.Distributed Systems like Git is more preferred for a open source project where several programmers work at different times and provide several updates to the code.

Hence Version Control systems have to be chosen based on the requirements of the project and its team.

References

<references/>

See also

External links