Concurrent Versions System

Last updated
Concurrent Versions System
Developer(s) The CVS Team
Initial releaseNovember 19, 1990;33 years ago (1990-11-19)
Stable release
1.11.23 [1] / May 8, 2008;15 years ago (2008-05-08)
Preview release
1.12.13 [2] / September 28, 2005;18 years ago (2005-09-28)
Repository
Written in C
Operating system Unix-like, Windows
Type Revision control
License GPL-1.0-or-later [3]
Website cvs.nongnu.org

Concurrent Versions System (CVS, or Concurrent Versioning System) is a version control system originally developed by Dick Grune in July 1986. [4]

Contents

CVS operates as a front end to Revision Control System (RCS), an earlier system which operates on single files. It expands upon RCS by adding support for repository-level change tracking, and a client-server model. [5]

Released under the terms of the GNU General Public License, CVS is free software.

Design

CVS operates as a front end to Revision Control System (RCS), an older version control system that manages individual files but not whole projects. It expands upon RCS by adding support for repository-level change tracking, and a client-server model. [5] Files are tracked using the same history format as in RCS, with a hidden directory containing a corresponding history file for each file in the repository.

CVS uses delta compression for efficient storage of different versions of the same file. This works well with large text files with few changes from one version to the next. This is usually the case for source code files. On the other hand, when CVS is told to store a file as binary, it will keep each individual version on the server. This is typically used for non-text files such as executable images where it is difficult to create compact deltas between versions.

CVS excludes symbolic links because when they are stored in a version control system they can pose a security risk. For instance, a symbolic link to a sensitive file can be stored in the repository, making the sensitive file accessible even when it is not checked in. In place of symbolic links, scripts that require certain privileges and conscious intervention to execute may be checked into CVS.[ citation needed ]

Operation

CVS labels a single project (set of related files) that 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 are reflected in the repository by committing them. To update is to acquire or merge the changes in the repository with the working copy.

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. CVS servers can allow "anonymous read access", [6] wherein 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. 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 conflicts, the server only accepts 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. Clients can also use the "update" command to bring their local copies up-to-date with the newest version on the server. Clients can also compare versions, request a complete history of changes, or check out a historical snapshot of the project (e.g.: based on a given date). If the check-in operation succeeds, then the version numbers of all files involved automatically increment, and the 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.

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 assumes that the majority of work takes place on the trunk, and that branches should generally be short-lived or historical. When used as designed, branches are easily managed and branch operations are efficient and fast. [7] [8]

Portability

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.

History

Grune recalled: [9]

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.

Grune publicly released the code on June 23, 1986. [10]

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. [11] On November 19, 1990, CVS version 1.0 was submitted to the Free Software Foundation for development and distribution. [12]

The latest version was released on 8 May 2008. [13]

Adoption and successors

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. [14]

Over time, developers have created new version control systems based on CVS in order to add features, alter the operational model, and improve developers' productivity. CVS replacement projects include CVSNT and Subversion. [15] [16]

See also

Notes

  1. ↑ Stable CVS Version 1.11.23 Released!
  2. ↑ CVS Feature Version 1.12.13 Released! * Security Update *
  3. ↑ "Contents of /ccvs/README".
  4. ↑ "CVS--Concurrent Versions System v1.12.12.1: Overview". Archived from the original on 15 April 2012. Retrieved 9 December 2011.
  5. 1 2 Stopak, Jacob (November 30, 2019). "The Evolution of Version Control System (VCS) Internals" . Retrieved 22 September 2020.
  6. ↑ Charles D. Cranor; Theo de Raadt (1999). "Opening The Source Repository With Anonymous CVS, USENIX 1999" (PDF). Archived (PDF) from the original on 2022-10-09.
  7. ↑ Collins-Sussman, Ben; Greg Ward (September 2004). "Subversion Users: Re: Performance (Subversion vs. CVS)". subversion-users. Retrieved 2010-07-07.
  8. ↑ West, Adrian (July 2004). "cvs branchtag performance fix". Archived from the original on 2009-08-03. Retrieved 2010-07-07.
  9. ↑ "Concurrent Versions System CVS". dickgrune.com.
  10. ↑ Dick Grune (July 3, 1986). "CVS, an RCS front-end (cvs)". Newsgroup:  mod.sources. Usenet:   122@mirror.UUCP . Retrieved September 14, 2016.
  11. ↑ "CVS II: Parallelizing Software Development - Berliner (ResearchIndex)". Archived from the original on September 9, 2004.
  12. ↑ "[cvs] Contents of /ccvs/NEWS". cvs.savannah.gnu.org.
  13. ↑ "Concurrent Versions System - News: Stable CVS Version 1.11.23 Released! [Savannah]". savannah.nongnu.org.
  14. ↑ Ben Collins-Sussman, Version Control with Subversion For Subversion 1.1, 2005
  15. ↑ "Subversion FAQ: Why does this project exist?". Subversion . Retrieved September 21, 2009.
  16. ↑ "Dispelling Subversion FUD". Ben Collins-Sussman. Archived from the original on July 18, 2011. Retrieved June 30, 2010.

Related Research Articles

In software engineering, version control is a class of systems responsible for managing changes to computer programs, documents, large web sites, or other collections of information. Version control is a component of software configuration management.

Revision Control System (RCS) is an early implementation of a version control system (VCS). It is a set of UNIX commands that allow multiple users to develop and maintain program code or documents. With RCS, users can make their own revisions of a document, commit changes, and merge them. RCS was originally developed for programs but is also useful for text documents or configuration files that are frequently revised.

<span class="mw-page-title-main">Apache Subversion</span> Free and open-source software versioning and revision control system

Apache Subversion is a software versioning and revision control system distributed as open source under the Apache License. Software developers use Subversion to maintain current and historical versions of files such as source code, web pages, and documentation. Its goal is to be a mostly compatible successor to the widely used Concurrent Versions System (CVS).

Rational ClearCase is a family of computer software tools that supports software configuration management (SCM) of source code and other software development assets. It also supports design-data management of electronic design artifacts, thus enabling hardware and software co-development. ClearCase includes revision control and forms the basis for configuration management at large and medium-sized businesses, accommodating projects with hundreds or thousands of developers. It is developed by IBM.

<span class="mw-page-title-main">History of software configuration management</span>

The history of software configuration management (SCM) in computing can be traced back as early as the 1950s, when CM, originally for hardware development and production control, was being applied to software development. The first software configuration management was most likely done manually. Eventually, software tools were written to manage software changes. History records tend to be based on tools and companies, and lend concepts to a secondary plane.

<span class="mw-page-title-main">GNU arch</span>

GNU arch software is a distributed revision control system that is part of the GNU Project and licensed under the GNU General Public License. It is used to keep track of the changes made to a source tree and to help programmers combine and otherwise manipulate changes made by multiple people or at different times.

<span class="mw-page-title-main">Git</span> Software for version control of files

Git is a distributed version control system that tracks changes in any set of computer files, usually used for coordinating work among programmers who are collaboratively developing source code during software development. Its goals include speed, data integrity, and support for distributed, non-linear workflows.

In software development, distributed version control is a form of version control in which the complete codebase, including its full history, is mirrored on every developer's computer. Compared to centralized version control, this enables automatic management branching and merging, speeds up most operations, improves the ability to work offline, and does not rely on a single location for backups. Git, the world's most popular version control system, is a distributed version control system.

Sun WorkShop TeamWare is a distributed source code revision control system made by Sun Microsystems. It was first announced in November 1992 as SPARCworks/TeamWare and ProWorks/TeamWare and made commercially available in 1993. Last available as part of the Forte Developer 6 update 2 product, TeamWare is no longer being offered for sale, and is not part of the Sun Studio product.

<span class="mw-page-title-main">Mercurial</span> Distributed revision-control tool for software developers

Mercurial is a distributed revision control tool for software developers. It is supported on Microsoft Windows, Linux, and other Unix-like systems, such as FreeBSD and macOS.

CVSNT is a version control system compatible with and originally based on Concurrent Versions System (CVS), but whereas that was popular in the open-source world, CVSNT included features designed for developers working on commercial software including support for Windows, Active Directory authentication, reserved branches/locking, per-file access control lists and Unicode filenames. Also included in CVSNT were various RCS tools updated to work with more recent compilers and compatible with CVSNT.

Microsoft Visual SourceSafe (VSS) is a discontinued source control program oriented towards small software development projects. Like most source control systems, SourceSafe creates a virtual library of computer files. While most commonly used for source code, SourceSafe can handle any type of file in its database, but older versions were shown to be unstable when used to store large amounts of non-textual data, such as images and compiled executables.

The Distributed Concurrent Versions System (DCVS) was a distributed revision control system that enables software developers working on locally distributed sites to efficiently collaborate on a software project. DCVS was based on the well known version control system Concurrent Versions System. The code was freely distributable under the GNU and BSD style licenses. The project was terminated sometime before late 2023.

Branching, in version control and software configuration management, is the duplication of an object under version control. Each object can thereafter be modified separately and in parallel so that the objects become different. In this context the objects are called branches. The users of the version control system can branch any branch.

In software development, version control is a class of systems responsible for managing changes to computer programs or other collections of information such that revisions have a logical and consistent organization. The following tables include general and technical information on notable version control and software configuration management (SCM) software. For SCM software not suitable for source code, see Comparison of open-source configuration management software.

<span class="mw-page-title-main">GNU Bazaar</span>

GNU Bazaar is a distributed and client–server revision control system sponsored by Canonical.

A sandbox is a testing environment that isolates untested code changes and outright experimentation from the production environment or repository, in the context of software development including Web development, Automation and revision control.

Azure DevOps Server is a Microsoft product that provides version control, reporting, requirements management, project management, automated builds, testing and release management capabilities. It covers the entire application lifecycle and enables DevOps capabilities. Azure DevOps can be used as a back-end to numerous integrated development environments (IDEs) but is tailored for Microsoft Visual Studio and Eclipse on all platforms.

In version control systems, a repository is a data structure that stores metadata for a set of files or directory structure. Depending on whether the version control system in use is distributed, like Git or Mercurial, or centralized, like Subversion, CVS, or Perforce, the whole set of information in the repository may be duplicated on every user's system or may be maintained on a single server. Some of the metadata that a repository contains includes, among other things, a historical record of changes in the repository, a set of commit objects, and a set of references to commit objects, called heads.

References

This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.