Concurrent Versions System

From Wikipedia, the free encyclopedia

You have new messages (last change).
Concurrent Versions System
Developer: The CVS Team
Latest release: 1.11.22 / 2006.06.09
Preview release: 1.12.13 / 2005.09.28
OS: Linux, Windows, FreeBSD, Mac OS X
Use: revision control
License: GNU General Public License
Website: www.nongnu.org/cvs/

The Concurrent Versions System (CVS), also known as the Concurrent Versioning System, implements a version control system: it keeps track of all work and all changes in a set of files, typically the implementation of a software project, and allows several (potentially widely separated) developers to collaborate. CVS has become popular in the free software and open-source worlds. CVS is released under the GNU General Public License.

Contents

[edit] Features

CVS uses client-server architecture: a server stores the current version(s) of the project and its history, and clients connect to the server in order to check-out a complete copy of the project, work on this copy and then later check-in their changes. Typically, client and server connect over a LAN or over the Internet, but client and server may both run on the same machine if CVS has the task of keeping track of the version history of a project with only local developers. The server software normally runs on Unix (although at least CVSNT server supports various flavors of Windows and Unix), while CVS clients may run on any major operating-system platform.

Several developers may work on the same project concurrently, each one editing files within their own working copy of the project, and sending (or checking in) their modifications to the server. To avoid the possibility of people stepping on each other's toes, the server will only accept changes made to the most recent version of a file. Developers are therefore expected to keep their working copy up-to-date by incorporating other people's changes on a regular basis. This task is mostly handled automatically by the CVS client, requiring manual intervention only when a conflict arises between a checked-in modification and the yet-unchecked local version of a file.

If the check-in operation succeeds, then the version numbers of all files involved automatically increment, and the CVS server writes a user-supplied description line, the date and the author's name to its log files. CVS can also run external, user-specified log processing scripts following each commit. These scripts are installed by an entry in CVS's loginfo file, which can trigger email notification, or convert the log data into a web-based format.

Clients can also compare different versions of files, request a complete history of changes, or check-out a historical snapshot of the project as of a given date or as of a revision number. Many open-source projects allow "anonymous read access", a feature that was pioneered by OpenBSD. This means that clients may check-out and compare versions with either a blank or simple published password (e.g "anoncvs"); only the check-in of changes requires a personal account and password in these scenarios.

Clients can also use the "update" command in order to bring their local copies up-to-date with the newest version on the server. This eliminates the need for repeated downloading of the whole project.

CVS can also maintain different "branches" of a project. For instance, a released version of the software project may form one branch, used for bug fixes, while a version under current development, with major changes and new features, forms a separate branch.

CVS uses delta compression for efficient storage of different versions of the same file. The implementation favours files with many lines (usually text files) - in extreme cases individual copies of each version are stored rather than a delta.

[edit] CVS terminology

A single project (set of related files) managed by CVS is called a module. A CVS server stores the modules it manages in its repository. Acquiring a copy of a module is called checking out. The checked out files serve as a working copy. One's changes to the working copy will be reflected in the repository by committing them. To update is to acquire the latest changes from the repository in the working copy.

[edit] History and status

CVS developed from an earlier versioning system called Revision Control System (RCS), still in use, which manages individual files but not whole projects. Dick Grune has provided some brief historical notes about CVS on his site. To quote:

I created CVS to be able to cooperate with my students Erik Baalbergen and Maarten Waage on the ACK (Amsterdam Compiler Kit) C compiler. The three of us had vastly different schedules (one student was a steady 9-5 worker, the other was irregular, and I could work on the project only in the evenings). Their project ran from July 1984 to August 1985. CVS was initially called cmt, for the obvious reason that it allowed us to commit versions independently.

—Dick Grune, Dick Grune's website

The code was publicly released to mod.sources on June 23, 1986: the original usenet post is still visible via Google Groups.

The code that eventually evolved into the current version of CVS started with Brian Berliner in April 1989, with later input from Jeff Polk and many other contributors. Brian Berliner wrote a paper introducing his improvements to the CVS program which describes how the tool was extended and used internally by Prisma, a third party developer working on the SunOS kernel, and was released for the benefit of the community under the GPL.

Nowadays, a group of volunteers maintains the CVS code. Notably, the development of the Microsoft Windows version of CVS has split off into a separate project named CVSNT and has been more active in extending the feature set of the system, even porting the changes back to the UNIX platform under the name CVSNT.

[edit] Relationship with GNU

Historically, the relationship between CVS and the GNU project could appear somewhat ambiguous: the GNU website distributed the program, labelling it "GNU package" on one page and "other GPL-licensed project" on another. This was recently clarified when CVS development moved from cvshome.org to savannah.nongnu.org, with CVS officially assigned to the non-gnu category. On the FTP site, the program has traditionally resided in the /non-gnu/ directory and still does.

[edit] Limitations

This is a difficult and perhaps contentious topic. It is a well discussed point that there are many aspects of CVS behaviour that the CVS development team are not changing. There are different points of view on the merits of that decision. If your point of view is that storing a symbolic link is a security risk and the creation of one should be a part of a build process not a version control process then the fact CVS doesn't store them is a feature. If your view is that storing symbolic links is the job of the version control system then it is a limitation.

About all that can be said definitively is that there are different points of view on the subject of what are limitations and what are carefully thought out positions on security and CM process design. What a person describes as a limitation is generally the lack of a feature, or an existing feature that the person has decided could be implemented in such a way that would be more effective for them.

A number of developers who wanted to change the CVS code significantly to add new features, refactor the code and improve developer productivity split from the project and began CVSNT (1st released 1998), OpenCVS (to be released soon) and Subversion (1st released 2004). These projects each address the limitations of CVS in different ways.

Over time many other projects (the External Links and See Also sections will guide you) have also copied CVS or used its code as a base to create a new version control tool, leading to the phrase YACC: "Yet Another CVS Clone".

For each commonly listed limitation of CVS there is also a commonly listed reason:

  • Moving or renaming of files and directories are not versioned. Refactoring should be avoided in a development process and can be managed by an administrator (by moving the RCS file) when it is (rarely) 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 counter intuitive.
  • 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.

The leaders and advocates of the CVSNT, OpenCVS and Subversion projects have different points of view - those linked pages and project web sites detail the arguments for their alternative approaches to these and many other topics.

[edit] See also

Portal:Free software
 Free software Portal
  • Revision control, a general overview of version control concepts
  • CVSNT - a better CVS, in various respects. Multi-platform, despite the name.
  • A list and comparison of revision control software
  • DCVS, a distributed revision control system based on CVS
  • TortoiseCVS, a shell-integrated CVS client for Windows
  • Subversion, an open-source revision control system, which aims to be a compelling replacement for CVS
  • Bonsai CVS code management system, a tool to reports on files, directories, and branches under CVS management.

[edit] References

[edit] External links

Retrieved from "http://en.wikipedia.org../../../c/o/n/Concurrent_Versions_System_cdf4.html"