Distributed Concurrent Versions System

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

Distributed Concurrent Versions System
Developer(s)elego Software Solutions GmbH
Initial releaseAugust 2002 (2002-08)
Stable release
1.0.3 / September 25, 2006 (2006-09-25)
Written inC
Operating systemUnix-like, Windows
TypeRevision control
LicenseGNU General Public License
Websitedcvs.elegosoft.com

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.

gollark: Some uses: if you are going shopping in a real-world shop you could get reviews displayed on the items you look at; it could be a more convenient interface for navigation apps; you could have an instructional video open while learning to do something (which is already doable on a phone, yes, but then you have to either hold or or stand it up somewhere, which is somewhat less convenient), and with some extra design work it could interactively highlight the things you're using; you could implement a real-world adblocker if there's some way to dim/opacify/draw attention away from certain bits of the display.
gollark: There's nothing you can't *technically* do with a phone, but a more convenient interface does a lot.
gollark: There are rather a lot of cool uses for being able to overlay information on reality.
gollark: I think you're being uncreative.
gollark: You can also do really fast automatic flight with Plethora kinetic augments.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.