• Save
Version Control With CVS
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Version Control With CVS

on

  • 5,289 views

scmGalaxy.com is dedicated to software configuration, build and Release management. This covers CVS, VSS (Visual Source Safe),Perforce, SVN(Subversion) MKS Integrity, ClearCase,TFS,CM Synergy, Best ...

scmGalaxy.com is dedicated to software configuration, build and Release management. This covers CVS, VSS (Visual Source Safe),Perforce, SVN(Subversion) MKS Integrity, ClearCase,TFS,CM Synergy, Best Practices ,AnthillPro, Apache Ant, Maven, Bamboo, Cruise Control and many more tools.

File Can be downloaded from:
http://community.scmgalaxy.com/

Statistics

Views

Total Views
5,289
Views on SlideShare
4,785
Embed Views
504

Actions

Likes
3
Downloads
62
Comments
0

7 Embeds 504

http://www.scmgalaxy.com 489
http://www.slideshare.net 4
https://www.linkedin.com 4
http://translate.googleusercontent.com 3
http://scmgalaxy.com 2
http://webcache.googleusercontent.com 1
http://www.linkedin.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Version Control With CVS Presentation Transcript

  • 1. Version control with CVS www.scmGalaxy.com scmGalaxy Author: Rajesh Kumar [email_address]
  • 2. 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
  • 3. 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?
  • 4. 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
  • 5. CVS – concurrent versioning system
  • 6. 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
  • 7. 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
  • 8. 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
  • 9. 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
  • 10. 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
  • 11. 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.
  • 12. 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
  • 13. 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.
  • 14. Installation and setup of CVS
  • 15. Exercise
    • Exercise 1 – install CVS
  • 16. 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
  • 17. Internals of a repository
  • 18. 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
  • 19. 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
  • 20. 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
  • 21. 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
  • 22. 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
  • 23. CVS – authentication and authorization
  • 24. 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
  • 25. 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
  • 26. 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
  • 27. 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
  • 28. 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
  • 29. 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
  • 30. 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
  • 31. 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
  • 32. 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
  • 33. 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
  • 34. Exercise
    • Exercise 2
  • 35. CVS client operations
  • 36. Files in the repository
  • 37. 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
  • 38. Exercise
    • Exercise 3
  • 39. Demo
    • Demonstrate setting up of eclipse with CVS
  • 40. Exercise
    • Exercise 4
  • 41. 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
  • 42. 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
  • 43. 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
  • 44. 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
  • 45. Demonstrate
    • Setting up tags
    • Retrieving files based on a tag
    • Diff between 2 tags
    • Reusing the same tag name across versions
  • 46. 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
  • 47. Exercise
    • Exercise 5
  • 48. 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
  • 49. 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
  • 50. Branching in CVS
  • 51. Demonstrate
    • Demo branching
    • Demo retrieval of code from a particular branch using win cvs and eclipse
    • Demonstrate merging back of files between 2 branches
  • 52. 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?
  • 53. 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
  • 54. 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
  • 55. 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
  • 56. Exercise
    • Exercise 6
  • 57. 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
  • 58. Other SCM tools Projects in Mindtree Consulting
  • 59. 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
  • 60. 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 
  • 61. 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
  • 62. 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
  • 63. 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  
  • 64. 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 
  • 65. 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. 
  • 66. 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 
  • 67. 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
  • 68. 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/
  • 69. www.scmGalaxy.com Thank You ! Author: Rajesh Kumar [email_address]