Distributed Concurrent Versions System
| Distributed Concurrent Versions System | |
|---|---|
| Basic data
|
|
| developer | elego Software Solutions GmbH |
| Publishing year | August 2002 |
| Current version | 1.0.3 (September 25, 2006) |
| operating system | unixoid , Windows |
| programming language | C. |
| category | Version management |
| License | GNU General Public License |
| https://www.elegosoft.com/ | |
The Distributed Concurrent Versions System (DCVS) is a distributed version control system that enables software developers who work at locally distributed locations to work efficiently on a software project. DCVS is based on the well-known version control system Concurrent Versions System . The code is freely available under the GNU and BSD- like licenses.
motivation
CVS is based on a purely centralized organizational model and offers very little offline support. Almost all version control operations require direct access to the repository . Therefore, software developments distributed around the world are faced with major performance problems when using CVS. DCVS counteracts this problem by distributing the central CVS repository to many locations.
Features
DCVS offers the entire CVS functionality. But unlike CVS, a DCVS system can contain any number of geographically dispersed repositories, the contents of which are kept the same in the background by an enhanced version of CVSup , a program developed by John D. Polstra . The combination of DCVS repository, extended CVSup server and DCVS server program is referred to below as the DCVS server.
All contents of all development lines can be checked out from any of the DCVS servers to a DCVS workspace of a developer. All operations that do not change the repository, such as B. diff , patch , log, annotate, etc., work just like in CVS, but always use the local repository and are therefore much faster in a distributed scenario. To avoid collisions and data loss, each DCVS server is assigned a set of development lines (DCVS branches) for which it is responsible. Changes to a branch may only be checked in on the server responsible for the branch. The separation of changes according to development lines enables changes to be automatically transferred to the DCVS network and distributed. A person who wants to commit changes to a development line for which their local DCVS server is not responsible can create a new development line (branch) and transfer the changes to it. The local server is automatically responsible for each newly created development line.
On the other hand, every developer can merge changes in development lines, for which his local DCVS server is not responsible, into local development lines. This means that all changes that are made at any place of work can be transferred to the original branch by the developers on the responsible DCVS server using a merge operation.
The change set functionality allows developers to create small sets of changes related to a feature or defect that can then be applied by others.
A special numbering scheme ensures that development lines and deltas can be identified as belonging to a specific DCVS server. DCVS assigns a unique range of branch numbers to each pair (server / collection) . All areas for all servers and collections must be mutually exclusive. The definitions for servers, collections and areas are read from a single configuration file. Based on the content of this file, each DCVS server can decide whether it is responsible for a specific branch or a delta of a specific file. If this is the case, all change operations are permitted; if this is not the case, change operations are only possible on the corresponding remote server.
The actual names of configurations, the tags , are also uniquely assigned to a DCVS server by a server- specific suffix that extends all tags (e.g. _at_dcvs_mydomain_org). This means that no conflicts may arise in the tag namespace.
history
DCVS was developed by employees of Elego Software Solutions GmbH in Berlin . The first version of DCVS was published in August 2002. Version 1.0.2 was published in November 2005.