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
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?
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
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
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
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
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
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
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.
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
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.
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.
Installation and setup of CVS
Exercise Exercise 1 – install CVS
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
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
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
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
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
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
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 Settingsmanojk>set CVSROOT=C:softwareCVS_MainRepositoriesClient_one C:Documents and Settingsmanojk>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
C:Documents and Settingsmanojk>set CVSROOT=C:softwareCVS_MainRepositoriesClient_one
C:Documents and Settingsmanojk>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
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
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
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
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
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
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
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
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
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
Exercise Exercise 2
Exercise 2
CVS client operations
Files in the repository
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
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
Exercise Exercise 3
Exercise 3
Demo Demonstrate setting up of eclipse with CVS
Demonstrate setting up of eclipse with CVS
Exercise Exercise 4
Exercise 4
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
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
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
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
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
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
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
Exercise Exercise 5
Exercise 5
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
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
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
Branching in CVS
Demonstrate Demo branching Demo retrieval of code from a particular branch using win cvs and eclipse Demonstrate merging back of files between 2 branches
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?
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
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
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
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
Exercise Exercise 6
Exercise 6
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
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
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
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
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
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
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
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.
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
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
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/
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]
Presentación que realice en el Evento Nacional de Gobierno Abierto, realizado los ...
In this presentation we will describe our experience developing with a highly dyna...
Presentation to the LITA Forum 7th November 2014 Albuquerque, NM
Un recorrido por los cambios que nos generará el wearabletech en el futuro
Um paralelo entre as novidades & mercado em Wearable Computing e Tecnologias Assis...
Microsoft finally joins the smartwatch and fitness tracker game by introducing the...
Home of CVS development, the code (source and binaries), documentation, third party add-ons, news, links.
Read more
The Concurrent Versions System (CVS), also known as the Concurrent Versioning System, is a client-server free software revision control system in the field ...
Read more
Für Versionsverwaltungssysteme ist die Abkürzung VCS (Version Control System) gebräuchlich. Hauptaufgaben ... (CVS) populär gemacht, ...
Read more
TortoiseCVS lets you work with files under CVS version control directly from Windows Explorer.
Read more
Which Version Control Software is right for your project? This definitive feature comparison guide will help you decide the best solution for you.
Read more
Version control systems ... in the presence of multiple repositories these may be based on a single original version ... CVS lacks this feature. File locking
Read more
Version Control with CVS¶ This chapter is not a CVS Tutorial. It focuses on the integration of CVS with Tuleap and how to use it in an optimal way in this ...
Read more
Windows CVS Software Software. Free, secure and fast downloads from the largest Open Source applications and software directory - SourceForge.net
Read more
CVS Software Software. Free, secure and fast downloads from the largest Open Source applications and software directory - SourceForge.net
Read more
Concurrent Versions System (CVS) ist ein Software-System zur Versionsverwaltung von Dateien, das hauptsächlich im Zusammenhang mit Software-Quelltext ...
Read more
Add a comment