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.

Motivation

CVS is based on a pure centralistic organizational model and offers very little offline support. Almost all version control operations require direct access to the repository. Therefore, worldwide distributed software development efforts face heavy performance problems when using CVS. DCVS tackles this issue by distributing the central CVS repository on many sites.

Features

DCVS provides all CVS functionality. But unlike CVS a DCVS system may comprise an arbitrary number of geographically distributed repositories whose contents are kept equal in the background by an extended version of CVSup, a program developed by John D. Polstra. The combination of DCVS repository, extended CVSup server and DCVS server program will be called DCVS server in the following paragraphs.

All contents of all development lines can be checked out from any of the DCVS servers into a DCVS workspace owned by a developer. All operations that do not modify the repository, such as diff, patch, log, annotate etc., work just like in CVS, but they always use the local repository and so are much faster in a distributed scenario. In order to avoid collisions and data loss every DCVS server gets assigned a set of development lines (DCVS branches) for which it is responsible. Modifications to a branch may only be checked in on the server which is responsible for the branch. The separation of modifications by lines of development makes it possible to automatically transfer and distribute changes in the DCVS network. A person wanting to commit changes for a development line that his local DCVS server is not responsible for can create a new development line (branch) and commit the changes to it. The local server is automatically responsible for any newly created line of development.

On the other hand, every developer can merge changes from development lines his local DCVS server is not responsible for into local development lines. Thus all changes made at any working site may be applied to the original branch by developers on the responsible DCVS server performing a merge operation.

The functionality of change sets enables developers to produce small sets of changes related to a feature or a defect, which can then be applied by others.

A specific numbering scheme ensures that development lines and deltas can be identified as belonging to a certain DCVS server. DCVS assigns a unique range of branch numbers to every pair (server/collection). All ranges for all servers and collections must be mutually exclusive. The definitions for servers, collections, and ranges are read from a single configuration file. By consulting the contents of this file, every DCVS server can decide if it is responsible for a certain branch or delta of a given file. If so, all modifying operations are allowed; if not, modifying operations are only possible on the appropriate remote server.

Also the actual names of configurations, the tags, are uniquely assigned to exactly one DCVS server by means of a server-specific suffix extending all tags (i. e. _at_dcvs_mydomain_org). Thus no conflicts in the tag name space may arise.

History

DCVS has been developed by team members of Elego Software Solutions GmbH in Berlin/Germany. The first release of DCVS was in August 2002. In November 2005 version 1.0.2 was released. The project was terminated sometime before late 2023, with the repository deleted.