Version Control With CVS

Version control with CVS www.scmGalaxy.com scmGalaxy Author: Rajesh Kumar [email_address]

Objectives Be able to setup an SCM tool (CVS) Be able to setup WinCVS client Be able to setup an IDE like eclipse against the CVS Be able to administer a CVS repository Understand how tagging, branching and merging works

Expectations My expectation Be able to configure an SCM tool in any project from the scratch Ensure that you get a good handle to various administrative features of CVS Ensure that you understand how authorization and authentication can be setup for a project Ensure that we discuss various strategies of tagging, branching and releasing code from CVS Give you an overview of other tools and their features Your expectations?

Agenda Introduction to CVS Installation and configuration of CVS Administration of a repository Authentication and authorization CVS client configuration Integration with Eclipse Tagging, Branching and merging Integrating eclipse with multiple branches Integration with ANT SCM tools comparison matrix

CVS – concurrent versioning system

Version management tools The primary features supported by most version management tools are Version management Concurrent development (lock or merge) Client server model Branching Tagging Multiplatform support Integration with IDE Multiple authentication modes

Selection criteria Criteria Locking and merging Authentication and authorization mechanism Need for distributed repositories / distributed clients Web interface Licenses (cost and ease of setup) Mostly the client / organization standard will be used as the default for a project However, in case we are presented with a ground up scenario, then the criteria listed above can be used for selection of the tool

Selection criteria – lock and merge Locking and merging Some tools allow multiple concurrent edits and a first come first serve check in. Others work on a lock and check-in mode. Some tools can be configured to function is either of the 2 ways The feature being supported by the tool should be well understood before the choice is made More important than concurrent editing is the conflict management and merge support Most tools support good merge features for text files Distributed development across locations may mandate a lock base editing

Selection criteria – Authentication mechanism Authentication and authorization mechanism The key question is how will users authenticate themselves and at what level can the authorization be provided Most tools support a simple text file based user repository creation and a simple name password based authentication Integrating the same with the organization wide security controller (windows PDC, UNIX user accounts etc.) could be advantageous Authorization at a file / directory level would be good to have, but administering the same will be an additional task Often within each folder, it may be imperative to setup file level permissions. In such cases a separate repository or a separate module within the same repository could be used

Selection criteria - distributed repositories Need for distributed repositories / distributed clients With the advent of distributed development the need for multiple teams accessing the same set of files from different locations arises Distributed locations brings with it the challenges of single repository (speed) and multiple repositories (synch up) Some tools like clear case support automated replication, while others like CVS only support repository synch up using a scheduled job The cons of one over the other needs to be understood while making the choice Dual repositories could bring with it issues when merging code

About CVS Written in the early 1990s as CVS for UNIX platform Built on top of an earlier popular SCM tool called RCS CVSNT is an offshoot from CVS and was created specifically for the NT platform It has more features such as PAM (pluggable authentication modules), integration with Windows authentication, binary files merge etc.

Advantages of using CVSNT Free and open source Large community of users Simple and easy to administer Rich basic level features – tagging, branching, revision control, scripts etc Allows authentication with windows domains Multiple connectivity options –ssh, ssl, plain sockets Supports notifications on commit Good documentation on the internet

What CVS does not support Fairly old code base and therefore comes with a few inefficiencies Renaming files and changes to directory structure are hard to manage Batch commits are not atomic (not transactional) Single central repository and does not support distributed repositories or auto-synch up etc.

Exercise Exercise 1 – install CVS

Demonstrate Demonstrate setting up of a repository Setup users in the passwd file Demonstrate importing a module into the repository Demonstrate adding a module into the repository Setup WinCVS to access the repository

Internals of a repository Each file of the project is stored as a ‘xxx,v’ file in the repository. The CVS folder in each directory has a file called fileattr.xml to help in file and directory level authorization

Internals of a repository - CVSROOT The CVSROOT is the directory where CVS stores all the administrative files Passwd – stores the pserver user IDs and passwords Email notification files History information files The config file has a few modifiable configurations LogHistory – used to configure the various log levels SystemAuth – used to specify the use of pserver auth mode Useradminoptions – used to specify if admin commands can be executed by all users

Internals of a repository – project files File storage The project directory is where the actual project files are stored in RCS format. This format ensures that the same file is used to store multiple versions of the file Historical, tag related, branch related data is stored in a single file Authorization File and directory level permission to various users can be controlled using OS level permissions – group and user level permissions CVS also provides utilities to manage file level authorization

How CVS works The CVSNT service listens to a port on the server for CVS commands One of the many protocols like SSH is used to send across commands from the client to the server The repository root, user information has to be sent each time one needs to execute a command The command executes on the local machine and as a part of the execution communicates with the server

CVS commands C:\Documents and Settings\manojk>set CVSROOT=C:\software\CVS_Main\Repositories\Client_one C:\Documents and Settings\manojk>cvs --help Usage: cvs [cvs-options] command [command-options-and-arguments] where cvs-options are -q, -n, etc. (specify --help-options for a list of options) where command is add, admin, etc. (specify --help-commands for a list of commands or --help-synonyms for a list of command synonyms) where command-options-and-arguments depend on the specific command (specify -H followed by a command name for command-specific help) Specify --help to receive this message

CVS – authentication and authorization

AT and AZ Authentication (AT) – the process of identifying a user and checking the password against the store Authorization (AZ) – the mechanism of granting certain roles / permissions to an authenticated user CVSNT (and CVS on Unix), support various authentication mechanisms such as Pserver – cvs manages the user IDs SSPI – CVS uses NT permissions Ext / ssh – cvs uses Unix users Authorization can be managed using file permissions or at a repository level

CVS protocols - pserver Pserver allows users to connect to CVS server using usernames and passwords stored in the CVS repository Each user has an alias NT user (can be reused for multiple users) Authorization is based on the alias NT user Password is stored on the server in an encrypted format :pserver:[[ user ][: password ]@][ hostname :[ port ]]/ path By adding users to the readers and writers file under the CVSROOT directory, users with read-only and read-write permissions can be defined Disadvantages for pserver protocol Password encryption is weak and over the network the password can be read and broken easily Generally advised not to use pserver protocol

CVS protocols - sserver Sserver Uses the passwd file as the store for user names and password The sserver protocol uses SSL as the communication layer and ensures that the password is communicated over SSL :pserver:[[ user ][: password ]@][ hostname :[ port ]]/ path

CVS protocols - SSPI SSPI Allows authentication using an NT user/password If the user is logged into the client machine then the user need not even send credentials to the server machine Different domain logins can be used :sspi:username@servername:/test The passwd file can list a subset of the NT domain users who should be allowed access NT file permissions can be used to authorize file / directory level permissions

CVS protocols - others Ext and ssh used more on the UNIX platforms Uses rsh mode of executing cvs commands Depends on UNIX authentication and user store Gserver Uses a GSS-API to support authentication Kserver Uses kerbros server for authentication Local Fork

Suggested ways to authentication Ssh, gserver, sserver Non-windows Non-windows Ssh Non-windows Windows sserver Windows Windows Protocol for authentication Server platform Client platform

Authorization and CVS In CVS, automatically the file and directory level permissions will be used to manage the authorization The permission given to the alias user (pserver) or the real users (sspi) will reflect on the cvs client At a repository level it is possible to control read and read-write access to the repository Using cvs commands a more fine grain ACL can be setup for each file if need be

AZ - Readers, writers and admin CVS allows setting up of users as read-only, read-write and admin users The CVSROOT in the repository has 3 files that define the roles of read-only, read-write and admin users At a repository level CVS allows the ability to setup 3 files Readers – userids appearing in this file will be given read-only access to the repository Writers – userids appearing in this file will be given read-write access to the repository admin – userids appearing in this file will be given rights to execute admin commands

Authorizing CVS administrators CVS administrators are a set of users who can execute the “cvs admin …” commands If the property SystemAuth in the config file is set to yes , then all users in the admin file and the systems administrators group will be given admin rights If the property SystemAuth in the config file is set to no , then only users in the admin file will be given admin rights In this file a list of users can be authenticated against pserver or the domain needs to be listed, 1 per line

AZ files and directories CVS allows setting up of file and directory level authorization Command: Cvs lsacl <filename> lists the file / directory level access control Command: cvs chacl –a <read,write> -u <userid> <resource – file / dir> Changes the acl for a file A combination of file permissions using NT user permissions and the acl commands can be used to control access at a file level

Demo Demonstrate check-in, update, commit Demonstrate the storage mechanism of text and binary files Demonstrate integration with external diff tool Demonstrate merge of files Demonstrate reserved edit Demonstrate graph Demonstrate conflict management

Demo Demonstrate setting up of eclipse with CVS

Keywords in CVS CVS is capable of examining the source file for a few keywords and replacing them with real time values E.g. $Author$ will be replaced with $Author: manoj$ with each check-in It makes the files capture the comments, time of check-in etc. It can help in tracing the need for the change and the user responsible for the change etc

Keywords - list Keywords list Author – user name Date – time of check-in Header – all header values, including author, date, path revision info etc. Name – name of the tag / branch into which the check occurred Log – the message given at the time of check-in Revision – the version number

Tagging CVS The number of versions that each file take is dependent on each owner However, when a delivery needs to be done, all files across multiple versions need to be taken. One needs to take these files and have the ability to recreate the version to solve a bug if need be Tagging allows us to set a string as the “tag” to various files each with different versions A tag is like a snapshot that can be recreated

Rules in tagging HEAD and BASE are reserved tag names HEAD – refers to the most recent version of a file in the trunk branch BASE – refers to the most recent version the client has synchronized with the repository Tag names is usually used to describe a release and is either the same or has a correlation to a release number too When a code base is tagged the BASE versions of the client will be tagged with the tag name A tag can also be moved with versions – same tag is used with each check-in to denote the latest file

Demonstrate Setting up tags Retrieving files based on a tag Diff between 2 tags Reusing the same tag name across versions

Note on tags Uses A tag can be used to retrieve files belonging to a particular release A tag can be used to check the number of modifications as compared to the previous release A tag can be given to a file, group of files, a directory or a module It is usually effective only at a module level It has very little impact on the space consumed, so it is a good practice to tag the repository often

Branching Branching provides us with a way to work on 2 separate branches of the same code repository It is aimed at providing an option to allow a repository multiple evolution cycles Each branch there on becomes a separate repository On a need basis branches can be merged with one another Branching as a feature is very powerful and needs to be exploited with care and a thorough strategy needs to be evolved before one proceeds with it

Use of branches Bug fix management - Use long branches for bug fixes, and merge the changes to the trunk. Experimental work , such as experimental code or a new web page design Major changes , such as a complete code rewrite Release candidates for testing - Use long branches, and merge changes to the trunk. You can convert the branch to a bug fix-management branch after release. Multiple versions of a product – use a branch to mark a release of a product version so that the same version can be recreated or supported after release

Demonstrate Demo branching Demo retrieval of code from a particular branch using win cvs and eclipse Demonstrate merging back of files between 2 branches

Branching strategies There is no single way to approach branching strategies However a few philosophies help in the strategy phase Primarily address the following questions When to branch? What should each branch be used for? Which branch should be sticky to which environment? How should merges be done?

Branch strategy 1 – Basically stable The basically stable philosophy advises that the trunk should have the stable version of code Here only release candidate code is merged with the trunk and the production environment takes a snapshot of the trunk Each time a release or a fix needs to be done, the trunk is branched off. Once QA certifies the stability of the code the branch is merged back to the trunk

Branch strategy 2 – Basically unstable Here the trunk has the latest code and not necessarily the most stable version. All development happens on the trunk and Each release is branched off separately for support The production version refers to one of release candidates

Merges Any 2 branches can be merged Freeze development and then begin a merge Use cvs tools / command line to get a list of conflicts Tag both branches before you merge Tag again after you have merged A merge does not mean that a branch is physically dead Think about merge frequency Always merge a support branch and the trunk before the trunk is branched off for a new release Each new release branch may need to synch up with the trunk at regular intervals

CVS continuous maintenance tasks Back up of the repository The repository directory can be backed up as though it were another directory Ensure that CVS server is stopped to avoid any access to the CVS server during backup In order to restore a repository, the restored directory can be setup as a new repository on a new server Using admin commands it is possible to remove particular versions of a file. Cleanup a few versions of binary files Use a SAN or a RAID disk to store repositories and reduce risk of disk crash

Other SCM tools Projects in Mindtree Consulting

Comparison of various SCM tools Parameters for comparing SCM tools Cost and licensing model Richness of client and command line tools Integration with IDE of choice Atomic commits Architecture Repository size and optimal storage Adaptability to name and structural changes Distributed and synchronous repositories Reliability Stability

CVS Free license and extensive online help  Many CVS clients – WinCVS, Tortoise CVS, CVSWeb etc  Excellent command line tools  Integrates with most IDEs – eclipse, VS.net etc  Commits are not atomic  Based on a client-server model  Stored text files in an incremental fashion. Repository size is less than other tools  Does not support renaming / copying of files  Does not support distributed and synchronous repositories. Repository itself can be replicated and setup afresh 

CVS (contd) Very reliable and is being used in most projects  Stable code base and good support for UNIX and Windows platforms   Works on a concurrent edit model. Widely accepted and still the most popular SCM tool

VSS Needs to be purchased separately. Usually comes along with MSDN, VS.net etc.  Proprietary client. No official web client Command line tool is satisfactory  Integrates well with VS.net. Plug-in to integrate it with eclipse. Not widely used by non-MS projects  Commits are not atomic  Based on a file share model. This means a check-in needs direct access (network share) to the repository. Access primarily intended over the intranet  File and internal DB is used. Repository size is usually larger than CVS

VSS (contd..) Partial support for file renaming and directory movement  Does not support distributed repositories Not known to be reliable (huge issues with version history loss)  The internal DB seems to have issues with large data and large teams. Corruption of the DB is widely reported  No support for UNIX clients   Works on a lock and edit model in most cases Used mostly in MS projects. Loss of data is an accepted fact across users  

Clear case Expensive and with enterprise features the cost goes up. Licensing is per seat  Proprietary client but the client is rich in features  Web views are supported  Integrates with leading IDEs  Commits are atomic  Proprietary RPC model of communication. Preferable to use it in the same LAN  Supports renaming and changing of repository structure  Excellent support for distributed repositories   Reliable and stable.  Support could be expensive 

Clear case Works on a lock and edit model. Users workspace can also be a shared folder managed by cc  One of the best tools with a rich feature list. Complexity and ramp-up time is high. Administrators are hard to find. 

Sub version Open source and free to use  Variety of clients. Most of them are under development  No web interface yet  Rich command line tool  Integrates with Eclipse. Other IDEs will follow suit  Commits are atomic  Client server model  Renames and structural changes are supported   Supports distributed repositories, using a 3 rd party utility  No reports of any major issues with reliability or stability  Has been created to deliver in areas where CVS is weak.  Most new projects in the non-MS arena choose Subversion  Support for more IDEs and rich online documentation will take it a long way 

In Summary If you have distributed teams and need to support multi-site then choose clear case. Cost could be high but administration will be easier If you have single shore team and need a reliable SCM – go for CVS or SVN. SVN may need more acceptance before it gets rich tools If you are working on a MS platform and team size is relatively small, choose VSS for ease of use with VS.net

References http://better-scm.berlios.de/comparison/comparison.html http://www.devguy.com/fp/cfgmgmt/cvs/ http://march-hare.com/cvspro/ http://cvsbook.red-bean.com/

www.scmGalaxy.com Thank You ! Author: Rajesh Kumar [email_address]

Version Control With CVS

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to Version Control With CVS (20)

More from Rajesh Kumar (20)

Recently uploaded (20)

Version Control With CVS