linux13 concurrent versions system

Concurrent Versions System

version control system

-1-

• CVS is a version control system. • Use to record the history of

your source files.

Concurrent Versions System

-2-

• For example, bugs sometimes creep in when software is modified, and you might not detect the bug until a long time after you make the modification.

Concurrent Versions System

-3-

• With CVS, you can easily retrieve old versions to see exactly which change caused the bug. This can sometimes be a big help.

Concurrent Versions System

-4-

• You could of course save every version of every file you have ever created. This would however waste an enormous amount of disk space.

Concurrent Versions System

-5-

• CVS stores all the versions of a file in a single file in a clever way that only stores the differences between versions.

Concurrent Versions System

-6-

• CVS also helps you if you are part of a group of people working on the same project. It is all too easy to overwrite each others' changes unless you are extremely careful.

Concurrent Versions System

-7-

• CVS solves this problem by insulating the different developers from each other. Every developer works in his own directory, and CVS merges the work when each developer is done.

Concurrent Versions System

-8-

• CVS started out as a bunch of shell scripts written by Dick Grune, posted to comp.sources.unix in the volume 6 release of December, 1986.

Concurrent Versions System

-9-

• CVS is primarily used as a source code control system for text files. Programmers will generate revisions to individual source code files. A collection of these files may define a specific software release.

Concurrent Versions System

-10-

• CVS aims to manage the collection of these files and the respective revisions of the individual files that make up the collection.

Concurrent Versions System

-11-

• CVS is a command driven file checkout, update, compare and management system. • CVS implements RCS for management

of individual files through the use of the CVS command set. Front end web and desktop GUI systems are available to ease in the use of CVS.

Concurrent Versions System

-12-

• CVS is a command driven file checkout, update, compare and management system. • CVS implements RCS for management

of individual files through the use of the CVS command set. Front end web and desktop GUI systems are available to ease in the use of CVS.

Concurrent Versions System

-13-

Set environment variables: (add to your .bashrc file)

Environment variables: # export

CVSROOT='/home/Project/CVS_root' (directory for CVS source code repository)

# export CVSEDITOR=/bin/vi

Setting up your environment for CVS:

-14-

Set environment variables: (add to your .cshrc file) (for csh users)

Environment variables:# setenv CVSROOT '/home/Project/CVS_root'# setenv CVSEDITOR /bin/vi

• CVSROOT: Location of CV source code repository.

Setting up your environment for CVS:

-15-

Set environment variables: (add to your .cshrc file) (for csh users)

Environment variables:# setenv CVSROOT '/home/Project/CVS_root'# setenv CVSEDITOR /bin/vi

• CVSROOT: Location of CV source code repository.

Setting up your environment for CVS:

-16-

• CVS stores all files in a centralized repository: a directory (such as `/usr/local/cvsroot') which is populated with a hierarchy of files and directories.

Basic concepts

-17-

You never access any of the files in the repository directly.

Instead, you use CVS commands to get your own copy of the files, and then work on that copy.

Basic concepts

-18-

The files in the repository are organized in modules.

Each module is made up of one or more files, and can include files from several directories.

A typical usage is to define one module per project.

Basic concepts

-19-

A revision number always has an even number of period-separated decimal integers.

By default revision 1.1 is the first revision of a file.

Revision numbers

-20-

Each version of a file has a unique revision number.

Revision numbers look like `1.1', `1.2', `1.3.2.2' or even `1.3.2.2.4.5'.

Revision numbers

-21-

Each successive revision is given a new number by increasing the rightmost number by one.

The following figure displays a few revisions, with newer revisions to the right.

Revision numbers

-22-

Revision numbers

CVS is not limited to linear development.

The revision tree can be split into branches, where each branch is a self-maintained line of development. Changes made on one branch can easily be moved back to the main trunk.

-23-

Each branch has a branch number, consisting of an odd number of period-separated decimal integers.

Revision numbers

-24-

The branch number is created by appending an integer to the revision number where the corresponding branch forked off. Having branch numbers allows more than one branch to be forked off from a certain revision.

Revision numbers

-25-

All revisions on a branch have revision numbers formed by appending an ordinal number to the branch number. The following figure illustrates branching with an example.

Revision numbers

-26-

Revision numbers

-27-

The exact details of how the branch number is constructed is not need to be concerned about. how it works: When CVS creates a branch number it picks the first unused even integer, starting with 2.

Revision numbers

-28-

So when you want to create a branch from revision 6.4 it will be numbered 6.4.2.

All branch numbers ending in a zero (such as 6.4.0) are used internally by CVS.

The branch 1.1.1 has a special meaning.

Revision numbers

-29-

A file can have several versions, as described above. Likewise, a software product can have several versions. A software product is often given a version number such as `4.1.1'.

Versions, Revisions and Releases

-30-

Versions in the first sense are called revisions in this document, and versions in the second sense are called releases.

To avoid confusion, the word version is almost never used in this document.

Versions, Revisions and Releases

-31-

• CVSNT keeps track of the version history of a project (or set of files).• CVSNT is based on the same

client-server architecture as the Concurrent Versions System: __

CVSNT

-32-

– a server stores the current version(s) of the project and its history, and clients connect to the server in order to check-out a complete copy of the project, work on this copy and then later check-in their changes.

CVSNT

-33-

• A server may be a caching or proxy server (a read only server that passes on write requests to another server) or a read and write (normal) server.

CVSNT

-34-

Concurrent Versions System

For More On CVS....Next Lecture....

-35-

Concurrent Versions System

LECTURE :: 2

-36-

• Access control for securing projects and branches.• Detailed audit and metrics

recorded in an SQL database.• Authentication with Active

Directory.

CVSNT Server features include:

-37-

• Tracking everything about the change - including whether it was merged from somewhere• A control panel to manage email

notification of changes, defect tracking integration, and more.

CVSNT Server features include:

-38-

• Integrated repository synchronization (for fail-over servers).• Supports UNICODE UTF-8/UCS-2

files and multi-lingual filenames.• Native servers available for Mac

OS X, Windows, Linux, Solaris, HPUX.

CVSNT Server features include:

-39-

• Supports reserved and unreserved versioning methodologies.• CVSAPI for integration into 3rd

party products.• Script, COM and 3GL interface for

triggers and integration into 3rd party tools (such as defect tracking)

CVSNT Server features include:

-40-

• CVSNT can do a lot of things for you, but it does not try to be everything for everyone.• cvsnt is not a build system.• cvsnt does not dictate how you

build anything. It merely stores files for retrieval in a tree structure you devise.

CVSNT Limitations:

-41-

• CVNT does not dictate how to use disk space in the checked out working directories. If you write your Makefiles or scripts in every directory so they have to know the relative positions of everything else, you wind up requiring the entire repository to be checked out.

CVSNT Limitations:

-42-

• CVSNT is not an automated testing program. • CVSNT does not have a built-in

process model.

CVSNT Limitations:

-43-

• It is possible to use CVS with multiple user but we take example for one user with user name foobar.

1.First Login as root, and execute the following.

Working With CVS

-44-

2) To provide cvs rights to "foofoo", but it can be any user on your system. # mkdir /usr/local/cvs # chown mark /usr/local/cvs

Working With CVS

-45-

3) Now login as "foobar" and do the following.

4) Edit your .bashrc file using vi or emacs or other, and enter these commands.

# CVSROOT=/usr/local/cvs

Working With CVS

-46-

5) Save and then execute "source .bashrc".

Now when you log in, it will setup your environment to use this directory by default if you don't specify a directory to use.

Working With CVS

-47-

6) Make a directory, which is need for cvs.

# mkdir /usr/local/cvs/CVSROOT

7) Upload files to the CVS repository

Working With CVS

-48-

Its All A

bout CVS

Thank You....!!!!

-49-