DCVS extends the version control system CVS and the file distribution and synchronization program CVSup with functionality to distribute CVS repositories with local lines of development. DCVS handles synchronization of the distributed repositories automatically in the background.
CVS only deals with a single, central repository. DCVS adds support for distributed, replicated repositories.
The new concepts of DCVS are:
A snapshot is simply a map of file names to specific revision numbers. The concept is similar to a TAG, but in contrast, a snapshot is stored as a single, separate file, independent of the repository files themselves.
A snapshot is an explicit way to denote a bound configuration. It is stored as a single plain text file below `snapshots', a subdirectory of the DCVSMETA module. Within this directory, snapshot files may be organized in a file system hierarchy.
Snapshots contain meta information about when and how they were created, by whom and by which command. Here is an example snapshot called `site-A/elego/dcvs/release-1.0':
# File: /example/DCVSMETA/snapshots/site-A/elego/dcvs/release-1.0 # Created: Tue Oct 11 17:25:54 2005 # Creator: neels # Command: dcvs mksnap -D 2004-12-24 elego/dcvs/release-1.0 # Description: first official release of DCVS PkgTags 1.1 cvsup/getlogs.sh 1.1.1.1 cvsup/mkflist.sh 1.1.1.1 cvsup/Announce 1.2 cvsup/Blurb 1.2 cvsup/Install 1.2 cvsup/License 1.2 cvsup/Makefile 1.6 cvsup/Acknowledgments 1.1.1.2 cvsup/ChangeLog 1.3 ... tkdcvs/tkdcvs/tkdiff/PATCHES 1.1.1.1 tkdcvs/tkdcvs/tkdiff/tkdiff 1.1.1.1 tkdcvs/tkdiff/COPYING 1.1 tkdcvs/tkdiff/PATCHES 1.1 tkdcvs/tkdiff/tkdiff 1.1
Changesets are, like snapshots, explicit mappings of file names to revision numbers, kept in a single plain text file, independent of the repository files themselves.
A changeset is an explicit way to denote the difference between two configurations, thus every file name is mapped to two revision numbers. One of the revisions may be `-', to indicate that the file does not exist in that configuration.
A changeset is stored as a single plain text file below `changesets', a subdirectory of the DCVSMETA module. Within this directory, changeset files may be organized in a file system hierarchy, similar to snapshots.
Changesets contain meta information about when and how they were created, by whom and by which command. Here is an example changeset called `/site-A/elego/dcvs/release-1-fix-02':
# File: /example/DCVSMETA/changesets/site-A/elego/dcvs/release-1-fix-02 # Created: Fri Oct 14 10:50:54 2005 # Creator: neels # Command: dcvs mkcset -r release-1-0-0 -r release-1-0-1 # Description: fixes for issues 224, 265, and 887 PkgTags 1.1 1.2 cvsup/Announce 1.2 1.3 cvsup/Blurb 1.2 1.3 ... tkdcvs/tkdiff/PATCHES 1.1 1.2 tkdcvs/tkdiff/tkdiff 1.1 1.2
DCVS is free software, distributed under a BSD-style (CVSup part) license and GNU license (CVS part). You can obtain DCVS from http://dcvs.elegosoft.com/
You can also download DCVS via CVSup or read an overview of DCVS.
Each server belonging to the DCVS replication network has at least on repository. This repository consists largely of replicated development lines, which are owned by other servers of the network, and of the relatively few branches owned by the host itself. All repositories belonging to the network are synchronized in intervals according to setting. Therefore they are most of the time consistent.
In contrast CVS uses exactly one writeable repository for all client workspaces. Standard CVSup application only allow for read-only copies.
DCVS integrates the tools and assures robust operation. DCVS avoids desasters by ensuring uniqueness of deltas and tags across all repositories. DCVS facilitates write access to different development lines of one softwareproject on an abitrary number of locally distributed workplaces. DCVS provides new features for the handling of complex configurations (snapshots, changesets)
DCVS currently has advanced 'beta' quality.
DCVS provides functionality and safeguards for replicating CVS repositories. It knows about the replication network and branch ownership and makes sure that data transfers do not corrupt the state of the replicated repositories.
Each host participating in the replication network is assigned a certain range of numbers (such as 1...2999, 3000...4999), which can be used to name the servers own branches. That means, that each branch belongs to exactly one range and is owned by exactly one host. As mentioned in question number 1 ranges must not overlap.
The dcvs program can be used as a command-line client. The cvs program can be used as a command-line client if the environment variable CVS_SERVER is set to "dcvs". GUI tools like tkCVS can be used with either a standard cvs client as backend (again, this requires having CVS_SERVER="dcvs" in your environment), or with the dcvs program as backend (this may require modification of the GUI tool).
You can get the sources with cvsup. Assuming you want to checkout the sources to the directory /home/<user>/dcvs, create a configuration file for cvsup called 'supfile' containing the following:
*default host=birch.elego.de *default base=/home/<user>/dcvs/cvsroot *default prefix=/home/<user>/dcvs/db *default release=. *default delete use-rel-suffix *default compress *default preserve dcvs
Then run 'cvsup -g supfile' on the command line. The -g option is optional. It turns the graphical user interface off.
No. Exactly one host in the replication netwok must be the master of any given branch. In order to commit changes to a branch it must be checked out from its master host. If a branch is checked out from a replica, changes cannot be commited to it. Changes may always be commited to a new branch and then merged to their intended destination.
Yes. But if a replica is checked out from a slave server of its master, r/o permissions are assigned. It is not possible to commit changes on the replica to the repository.
Yes. With DCVS you can delegate development lines (branches) to certain servers, which thus become the master server of that branch. On that server (and only there) you can work locally on the branch and commit the changes.
No. Once a new development line has been delegated to its master server, it must be checked out from its master server for modification. However, you can check out a replica of that development line and create a new branch under the range of this particular server.
No, CVSup can be used to replicate the changes made in the branch on its master server to the slave servers.
The concept of master servers in DCVS allows the distribution of changes on development lines throughout the entire server network without the risk of conflicts. By assigning r/w permission according to the branch ownership DCVS makes sure that data transfers do not corrupt the state of the replicated repositories. Otherwise it would be possible that developers check out the same branch on two different servers at the same time. They would accomplish modifications to the branch and when checking in or, as therepositories of the DCVS system must not permanently be connected, at least when synchronizing the repositories a conflict would arise which could not be resolved. To avoid this situation DCVS knows the branch ownership of servers.
There is only replication taking place across server boundaries. However, you can check-out a replica from the repository and merge it into any development line owned by your host. But you can't merge the branch owned by your server into a replica of another server.
First of all you can only carry out a merge action in your workspace. In repositories new versions are stored, there is no merging taking place. Across server boundaries there is only replication possible, you can not change ownership of a branch. Therefore the foreign repository will deny the check in. But the branch owner is able to merge a replica of another host into his own branch or trunk. Conventional CVS operations carry out this action.
Theoretically under certain circumstances it is possible. But there are several reasons why this kind of action is not desirable. First the files in your workspace are bound to the repository of your local host by meta information in the CVS sub-directories (.../CVS/Root, .../CVS/Repository). If you directly want to communicate with a foreign server, you can override the binding by using the option -d. For example:
dcvs -d sunflower:/repo commit.
Second there is a reason why DCVS had been installed. That is if there is any connection to sunflower it is probably a very slow one. Third it might be the case that anyone of server sunflower has checked in changes to the same version in between which means that the version which you had checked out isn't any more the HEAD of the branch. In this case DCVS will refuse the commit and ask you to update your workspace. Then you will have to merge the changes you have made into the new HEAD. Then when trying to check in your changes the same situation might happen to appear again.
On the client-side, dcvs and regular cvs can be used interchangeably. Note that for regular cvs clients to work with dcvs servers, the environment variable CVS_SERVER="dcvs" must be set on the client side.
If you only want to replicate in one direction (from site A to site B) and allow local branches on B, it should be possible to use CVS at A on server- and client-side and DCVS at B.
ATTENTION: We have not tested this setup thoroughly yet.
Once you make the move from CVS to DCVS on any site, you must ensure that the needed locking directory exists in DCVSROOT for mutual exclusion of cvsup and dcvs processes, but that should be trivial. And you will of course have to make sure that all workspaces are migrated, too, that is, everything is checked in with CVS for a last time and then checked out with DCVS again. NO GUARANTEE
For the client software DCVS runs on windows 2000 so far. Other windows platforms will follow soon
The DCVS server software has to run on a Unixlike system because the CVSup daemon is entirely written as a Unix system daemon. To make the DCVS server software windows compatible extensive work on the CVSup code is required, which would be a great contribution to the DCVS project. As long as nobody has time (or interest) in doing this, there is another possible solution: You can try to run the CVS part of DCVS on Windows, export the file system via NFS or SMBFS and run the cvsup synchronizations only at safe times on a Unix machine (problem here is the mutual exclusion of cvsup and dcvs binaries). Or (easiest) you just use a Unix server for the(d)cvs and cvsupd daemon processes.
If there is a problem running the 'standard' CVS source on the Windows system, you might be better off by integrating the changes into the sources of your Windows supporting CVS system. NO GUARANTEE
The author of Meta-CVS has contacted me about this topic. He intends to integrate DCVS into Meta-CVS. Thus we are convinced that the next Meta-CVS release works together with DCVS out of the box.
No. An import in CVS goes to the vendor branch, which logically belongs to the trunk (main development line). This is covered by the 'base' range you have defined. It is impossible to have one server be responsible for the main development line and import the sources on another server.
When installing DCVS you should pay heed to several points:
ssh <dcvs-server-hostname> id
should work without producing anything but the remote id output for every user of DCVS.
This probably means that the initial synchronization step has failed. Given that there cannot have been local changes at the "subordinate" site, the repository of Daisy should be a true copy of the primary site repository. Refer to the following scripts for details:
dcvsupd.sh
starts the dcvsup server with correct arguments according to the DCVS configuration file
dcvsup.sh
starts a DCVS update for a given server with correct settings extracted from the DCVS configuration file
sdcvsup.sh
starts a DCVS update for a given server with correct settings extracted from the DCVS configuration file over a secure channel
dcvsup_push.sh
pushes changes from the local server to all other servers over unsecured channels via ssh
sdcvsup_push.sh
pushes changes from the local server to all other servers over secure channels via ssh
dcvs_locks.sh
lists, checks, or creates DCVS lock directories and files
dcvs_getconfig
is not a script, but an m3 program that can be used to extract information from a DCVS configuration file and very useful for script writing
Following setup is assumed:
range base 0...999 range r1 1000...1999 range r2 2000...2999 server sunflower server buttercup collection fragrance /repos/dcvs fragrance sunflower:base buttercup:r1 end collection aroma /repos/dcvs aroma sunflower:base buttercup:r1 end
fragrance und aroma are modules that are available in the base server sunflower
.sunflower masters the trunk and vendor branches of both fragrance and aroma, and buttercup is getting slave access to those collections.
Let's consider fragrance only.
Suppose there exists a tag (label) identifying a somewhat stable configuration of fragrance, called DEV_FRAGRANCE_PHASE8. The sunflower folk (the trunk owners) designate this as the baseline for changes that need to be made at the buttercup site.
sunflower% DCVSROOT=sunflower:/repos/dcvs; export DCVSROOT sunflower% cd fragrance sunflower% dcvs tag DEV_FRAGRANCE_PHASE8
A developer at the buttercup site would now check out a workspace from the buttercup repository with the DEV_FRAGRANCE_PHASE8 tag, the latest trunk changes having been replicated from sunflower to buttercup. She would then branch out from that label to get a writeable line of development; suppose this branch was named dev_fragrance_phase8_buttercup_mods:
buttercup% DCVSROOT=buttercup:/repos/dcvs; export DCVSROOT buttercup% dcvs co -r DEV_FRAGRANCE_PHASE8 fragrance buttercup% cd fragrance buttercup% dcvs tag -b dev_fragrance_phase8_buttercup_mods buttercup% dcvs up -r dev_fragrance_phase8_buttercup_mods
Note that the branch numbers at the buttercup site will be taken from the r1 range; thus, the DEV_FRAGRANCE_PHASE8_BUTTERCUP_MODS is automagically mastered at the buttercup site and eventually propagated to the sunflower site! This is the branch delegation step. Admittedly, it's somewhat implicit.
At the sunflower site, developers eagerly await the go-ahead to merge the dev_fragrance_phase8_buttercup_mods back into the trunk LOD. Eventually, they will use a straightforward (D)CVS merge to pull in the changes made at the buttercup site:
sunflower% dcvs up -A sunflower% dcvs up -j dev_fragrance_phase8_buttercup_mods ... resolve conflicts ... run regression tests ... sunflower% dcvs ci sunflower% dcvs tag DEV_FRAGRANCE_PHASE5
To avoid these kind of problems please study the appropriate Unix manuals and the manuals of your tools and your shell exhaustively! Nevertheless we will describe here some of the situations in terms of which we are frequently asked for advice.
If you want to call the dcvs programs, you must either use the full path (/usr/local/bin/dcvs...) or add the packages' binary directory to your program search path. How you do this, depends on your shell. For sh/ksh/bash use something like
PATH=${PATH}:/usr/local/dcvs/bin , for csh/tcsh do set path = ( $path /usr/local/dcvs/bin ) .
You will also have to create a global configuration file and set some appropriate environment variables (preferably in a global initialization file, like /etc/profile, /etc/bash.bashrc, /etc/csh.cshrc, etc.) as described in the installation instructions but depending on your setup/system.
Nothing, but at the end, the ssh-tunnel will be destroyed, which causes this error. your changes have been pushed and the script will terminate the tunnel.
Solution:05 7-20 * * * /usr/local/dcvs/etc/sdcvsup.sh host | grep -v Hangup 2>&1 > /dev/null
In the line
server lCVS localhost.localdomain [portnumber (standard 44555)]
the expression "localhost" must be replaced by the real name of your server and "localdomain" must be replaced by the real name of your domain.
The line in a configuration file defines one server with the short name (id) lCVS and the DNS name localhost.localdomain. This should resolve via DNS to an IP number where the server is run, i.e.
host localhost.localdomain
must give the local IP number.
When you use the call
/usr/local/dcvs/bin/dcvs -d :ext:lCVS:/repos/dcvs init
to initialize the repository, you explicitly specify server host `lCVS' to be contacted via the external access method (rsh/ssh). This host must also be resolvable in DNS, i.e.
host lCVS
must yield the correct IP number.
If you have set up the environment variables
DCVS_RSH=ssh DCVS_SERVER=/usr/local/dcvs/bin/dcvs DCVSROOT=:ext:dcvs1:/usr/dcvs
(customized to your needs), you can omit the -d CVSROOT option above. Depending on your requirements, you may also be able to use the Unix host table (/etc/hosts) instead of DNS for name lookup, but this seems only probable if you operate in your own, distributed (inter)network.
This is the default location and should be found immediately. The default locations searched for configuration file are
"/etc/dcvs_config", "/usr/local/etc/dcvs_config", "/opt/etc/dcvs_config", "/usr/local/dcvs/etc/dcvs_config", "/usr/local/etc/cvsup/cvsupd.servers", "/usr/etc/cvsup/cvsupd.servers", "/opt/etc/cvsup/cvsupd.servers". "/etc/dcvs/dcvs_config" "/usr/local/etc/dcvs/dcvs_config".
If DCVS cannot find the config file, please check the output of
dcvs -L4 -nq up.
You can override the default search path using the DCVS_CONFIG environment variable. For example if using your bash as your shell:
export DCVS_CONFIG=/path/to/dcvs/config-file.
You can simply use gdb; add the option @M3novm to the command arguments, and follow the code (use proper dir statements so that the sources can be found). You won't be able to see much of the data, though, but often it's enough to understand what's happening.Index: faq.html