Developer(s) | The CVS Team |
---|---|
Initial release | November 19, 1990 |
Stable release | 1.11.23 / May 8, 2008 |
Preview release | 1.12.13 / July 26, 2006 |
Written in | C |
Operating system | Unix-like, Windows |
Type | Revision control |
License | GNU General Public License |
Website | savannah.nongnu.org/projects/cvs |
The Concurrent Versions System (CVS), also known as the Concurrent Versioning System, is a client-server free software revision control system in the field of software development. Version control system software keeps track of all work and all changes in a set of files, and allows several developers (potentially widely separated in space and/or time) to collaborate. Dick Grune developed CVS as a series of shell scripts in July 1986. There was a similar system available earlier in the mid-'70s developed by John Humbert.[1]
CVS became popular with commercial software developers and also the open source software world and is released under the GNU General Public License. There is regular development to add features and fix bugs,[2] regular builds and test results [3] and a correlation between development and requests for new features or bug reports[4] which suggests[5] that the product is mature.
Contents |
CVS uses a client–server architecture: a server stores the current version(s) of a 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, the 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 the CVSNT server also supports various flavors of Microsoft Windows), 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 others' 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 an edit 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 versions, 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 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, can form a separate branch.
CVS uses delta compression for efficient storage of different versions of the same file. The implementation favors files with many lines (usually text files) - in extreme cases the system may store individual copies of each version rather than deltas.
In the world of open source software, the Concurrent Version System (CVS) has long been the tool of choice for version control. And rightly so. CVS itself is free software, and its non-restrictive modus operandi and support for networked operation – which allow dozens of geographically dispersed programmers to share their work – fits the collaborative nature of the open-source world very well. CVS and its semi-chaotic development model have become cornerstones of open-source.
— Collins-Sussman, Version Control with Subversion For Subversion 1.1, 2005
CVS labels a single project (set of related files) which it manages as a module. A CVS server stores the modules it manages in its repository. Programmers acquire copies of modules by checking out. The checked-out files serve as a working copy, sandbox or workspace. Changes to the working copy will be reflected in the repository by committing them. To update is to acquire or merge the changes in the repository with the working copy.
CVS developed from an earlier versioning-system called Revision Control System (RCS) (still[update] 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
Grune publicly released the code to mod.sources on June 23, 1986: Google Groups continues to archive and serve the original usenet post.
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. On November 19, 1990, CVS version 1.0 was submitted to the Free Software Foundation for development and distribution.[6]
CVS introduced the implementation of branching into version control systems: the branching techniques in other systems all derive from the CVS implementation as documented in 1990.[7] Whilst RCS did incorporate the concept of branches - they were for individual files only.
CVS has always solidly supported distributed, multi-site and offline operations due to the unreliability of the few computer networks that existed at the time CVS evolved.
Active development of CVS continues with new releases correlating directly with requests for new features or bug reports[8], with the latest version released May 2008, and only some maintenance bugfixes since then in the CVS project's own CVS repository.[9] which suggests[10] that the product is mature.
Development of the Microsoft Windows port 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.
Historically, the relationship between CVS and the GNU project could appear somewhat ambiguous: the GNU Web site distributed the program, labelling it "GNU package" on one page and "other GPL-licensed project" on another. Clarification came recently[update] 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.
The developers of CVS claim that many of the listed common criticisms of CVS were planned carefully and implemented intentionally into CVS:
Over time, developers have wanted to change the CVS code significantly to add new features, refactor the code, alter the operational model and improve developers' productivity. This has led to the phrase YACC: "Yet Another CVS Clone" (itself a play on the Unix command named yacc
, which stands for "yet another compiler compiler"). CVS replacement projects include CVSNT (first released 1998), EVS (first released 2008), OpenCVS (not released as of 11 April 2011[15]) and Subversion[16][17] (initially released in 2004[18]) and numerous systems to support distributed revision control.
|