VERSION CONTROL SYSTEM

What is Version Control System?

In technical term, it is a software tool, which helps in keeping track of all revisions and releases of a project's source code. (for each change: who, when, and why) Also called revision control system. is open-source and free

Why it is required?
Modern day software development or any field of study or development, involves a collective effort from multiple peoples for the speedy and efficient execution of work The multiple team members of a software development environment may have access to the same source, it becomes really unmanageable to track changes made by different users. Thus, a system is required which can be effectively used to track the changes and contribute towards collaborative development. Version Control System is one such system.

Classification and examples:

Distributed model each developer works directly with their own local repository, and changes are shared between repositories as a separate step

Open-source: GNU arch, Bazaar

Client-server model -

developers use a shared single repository

Local only: Revision Control System (RCS) Open-source:CVS, CVSNT, OpenCVS, Subversion, Vesta

Different Version Control System

SCCS: UNIX Source Code Control System
Rochkind, Bell Labs, 1972.

RCS: Revision Control System

Tichy, Purdue, 1980s.

CVS: Concurrent Versions System

Berliner, 1989.

Subversion (SVN)

a compelling replacement for CVS Jostein Chr. Andersen, 2003

Why CVS?
Several methods for tracking contribution and changes made by different users #1: Manual merging and coordination
It is not convenient when number of users are very large.

#2: Revision Control System (RCS), Source Code Control System (SCCS)
It manages individual files but not whole projects. (currently in use)

#3: Concurrent development (CVS)

It manages both individual files as well as whole projects.

CVS
CVS is stand for Concurrent Versions System, or Concurrent Versioning System

What does CVS do?

Uses a clientserver architecture.
Server(repository) stores entire history of each file. Clients connect to the server in order to read or edit file.

Allows multiple people to work simultaneously. Enables retrieval of old systems. Helps to manage different versions, releases. Works well over LAN, WAN (server/client). To avoid the possibility of conflict with each others work, the server only accepts changes made to the most recent version of a file. Works fine for any ASCII file, but limited support for binary files.
Treats files as text by default.

Problem with binary files.

For example, if someone else checked in a new version of a file, you may wish to look at what they changed and determine whether their changes are good. For text files, CVS provides this functionality via the cvs diff command. For binary files, it may be possible to extract the two revisions and then compare them with a tool external to CVS (for example, word processing software often has such a feature).

How does it works?

The heart of any version control system is a Centralized Repository, which contains the source code or documents on which versioning needs to be done. There are two different models on which these version control systems work. These are 1. Lock-Modify-Unlock Model 2. Copy-Modify-Merge Model

Lock-Modify-Unlock Model
In Lock-Modify-Unlock Model, when a developer wants to modify a particular file, he obtains a copy of that file from the centralized repository. At the same time, he locks the file on the repository to prevent the write access to other users. After making the changes to the obtained copy, developer updates the repository with the latest version and releases the lock. The file after unlocking is again accessible for modifications by other users. The user can obtain an editable version of the file, only if there is no existing lock on that file.

Copy-Modify-Merge Model
In this model, each developer can obtain a local copy of editable version of the file from the centralized repository. Each developer can freely edit their local copy and once they are done they merge these changes to the existing file in the repository. In this process, there is no file locking involved and so it allows developers to work on the same file simultaneously. In case there is conflict while updating a file on the repository, the system informs the developer about the conflicts.

Procedure(flow)
1. Create a new, empty repository. 2. Create a working copy. 3. Apply the modifications in the working copy to the repository as a new changeset. 4. Update the working copy with respect to the repository.

Procedure(flow)

Add

Edit

Delete

Rename

Move

Procedure(flow)

Status

Difference

Revert

Log

Tag

Branch

Merge

Resolve

Lock

Updating a file
Scenario:
Monday morning Jainam checked out the file monalisa.bmp, while Sagar checked it out early afternoon
The version that each works on is version number 11 of that monalisa.bmp

In the evening, Jainam is done and checks in his version (which becomes version 12 in the repository)
He sends Sagar an email saying that hes finished his changes are already in the repository

On Tu morning, Sagar does an update of the file to bring into his local copy all the changes that Jainam made the previous day:
>> cvs update recipe.txt

Recall the update then check-in rule

Resolving conflicts
Having to resolve conflicts is anything but fun

Scenario:
Monday morning Jainam checked out the file Monalisa.bmp, while Sagar checked it out early afternoon
The version that each works on is version number 11 of that file

Due to a communication hiccup, they both end up modifying the recipe for the spicy cookies
Sagar is more familiar with the recipe, checks in his changes first (repository now holds on to version 12) Jainam follows the update then check-in convention, but when he updates, his modifications of the file, conflict with Sagars (they both modified exactly the same part of the file Monalisa.bmp)

Resolving conflicts (cntd.)

Key question: which changes should be kept? Jainams or Sagars?
CVS cannot know whos more deserving (they both are) Its none of CVS business to decide what changes should be overwritten by the other changes When Jainam does the update, CVS will simply flag the regions of the file that conflict and it will be up to Jainam and Sagar to figure out this Jainam will have to clear all the flags, and since he was the one dealing with the conflicts will have to check in what becomes version 13 of monalisa.bmp

 Suggested policies

 How does CVS store multiple versions of the same file?

 vesrion

 Software
Online Offline One software procedure (working)

 Advantages of cvs

 conclusion

 Usefull links