Software Testing Social Network

Concurrent Versions System ( CVS)

• What is CVS?

• Evolution of CVS

• What you can do?

• Terminology used

• Using CVS for development

• CVS commands

• Advantages of CVS

• A word of caution

What is CVS?

• Open source Version Control System

• Maintains records of files throughout their development

• Allows retrieval of any stored version of a file

• Supports production of multiple versions

Evolution of CVS

• Invented & developed by Dick Grune in the 1980s

• developed from an earlier versioning system called Revision control system (RCS)

• CVSNT – a Microsoft Window version

• Open CVS – to be released soon

Terminology used

• Module: A single project (set of related files) managed by CVS is called a module.

• Repository:  A CVS server stores the modules it manages in its repository. 

• Checking out (cvs checkout): Acquiring a copy of a module is called checking out.

• Working copy: The checked out files serve as a working copy, sandboxworkspace.  or

• Committing (cvs commit, cvs watch): Changes to the working copy will be reflected in the repository by committing them.

• Update (cvs update):To update is to acquire or merge the changes in the repository with the working copy.

Using CVS for development

•   Developers check out a personal sandbox — a personal copy of the project's files — to work from.

•   After the initial release of a program, two versions usually need to be maintained: the new version that will eventually be the next release and the bug fix version for the current release (trunk and a branch).

•   Multiple developers can work simultaneously on the same project or file without loss of data

•   Instead of locking files to prevent conflicts, CVS simply allows multiple developers to work on the same file.

CVS Commands

• Login (cvs login)

• Checking out (cvs checkout)

• Committing (cvs commit, cvs watch)

• Update (cvs update)

• View Log information (cvs log)

Advantages of CVS

•   Any stored revision of a file can be retrieved to be viewed or changed.

•   The differences between any two revisions can be displayed.

•   Multiple developers can work simultaneously on the same project or file without loss of data

•   The project can be branched to allow simultaneous development.

•   Distributed development is supported across large or small networks. ( CVS offers a variety of authentication mechanisms.)

•   The CVS approach prevents one developer from blocking another, thus increasing productivity.

Disadvantages

• Moving or renaming of files and directories are not versioned. It was implemented this way because in the past Refactoring was avoided in development processes. More recently the thinking has changed and refactoring can be managed by an administrator (by moving the RCS file) as it is required. If you develop in Oracle Forms, Cobol, Fortran or even C++ then the CVS reasoning is quite commonly accepted; if you develop with Java then the CVS reasoning may seem counterintuitive.

• No versioning of symbolic links. Symbolic links stored in a version control system can be a security risk - someone can create a symbolic link index.htm to /etc/passwd and then store it in the repository; when the "code" is exported to a Web server the Web site now has a copy of the system security file available for public inspection. A developer may prefer the convenience and accept the responsibility to decide what is safe to version and what is not; a project manager or auditor may prefer to reduce the risk by using build scripts that require certain privileges and conscious intervention to execute.
  Limited support for Unicode text files and non-ASCII filenames. Unix systems run in UTF-8 and so CVS on Unix handles UTF-8 filenames and files natively. If you only work on Unix systems then this response seems reasonable; however when you work on AS/400 and Windows it may not since the (original) CVS clients on these systems do not translate the filenames to the codepage of the server.
  

• No atomic commit. The network and server that is being used should be reliable enough that a commit can complete without either crashing. In many CM processes development work is performed on branches (eg: add feature A1234) and then merged into the trunk after code review - that final merge is 'atomic' and performed in the data center by QA.
  

A word of caution

•   Version control is not a substitute for team members communicating with each other.

•   File updates should be passed through CVS, but the meaning of the changes must be passed to other team members by actually discussing them.

Comments (0)

Subscribe to this comment's feed