Distributed CVS -- Synchronizing Multiple CVS Repositories

Distributed CVS -- Synchronizing Multiple CVS Repositories

Post by Olaf Wagne » Tue, 24 Sep 2002 21:54:09

Distributed Concurrent Versions System (DCVS) Technology Preview

   DCVS extends the well-known version control system
   CVS and the file distribution and synchronization program
   CVSup with functionality to distribute CVS repositories
   with local lines of development and handle synchronization of
   the distributed repositories automatically in the background.

   DCVS is completely open source (BSD and GNU license); a
   first technology preview release is now available from
   elego Software Solutions GmbH, Berlin, Germany at


   Some information is also available from the product pages of
   CM Magazin, a German language SCM portal site:


   If you have ever wondered how to synchronize your distributed
   CVS repositories and allow local lines of development, this
   is the way to go.

   The sources now available contain only the minimum of
   needed functionality and require some know-how to set up
   correctly; we're currently looking for testers who will
   work with us to stabilize the software before continuing
   development in such areas as easy configuration, setup,

   If you are interested in DCVS or willing to participate in
   a beta test phase, please drop us a line.

   DCVS has been developed on FreeBSD 4.6; currently we provide
   binaries for FreeBSD and Linux.
elego Software Solutions GmbH                           HRB 77719

Ohmstra?e 9                               Tel: +49 30 40 04 19 29
10179 Berlin                              Fax: +49 30 23 45 86 95
Cranachstra?e 7                           Tel: +49 30 85 58 01 81
12157 Berlin                              Fax: +49 30 85 58 01 88
  ------------------> WWW: http://www.elego-software-solutions.com


1. CVS-utils/improvements for backups & distributed repositories

I'm considering writing perl scripts or modifying cvs giving support
for keeping backups in the best possible way. However, I don't want to
reinvent the wheel - so I'm wondering if this, or something similar
might exist. I'd also like some feedback; Is there anybody else that
might be interested if I write those scripts? Do you have opinion on
my ideas? Is this just a waste of time, or are those ideas so
brilliant they should even be incorporated in the next version of CVS?

Very shortly, I want to write something like:

cvs rawbackup - | gzip -c9 > /dev/tapedevice
cvs restorebackup - < /dev/tapedevice
cvs chksumtst chksumfile
cvs outdateundo <backup-repository> <revision(s)(range)>

More detailed, my proposal is to create commands (or scripts) doing:

* Chksum export
Creates a control file with all revisionnumbers and checksums.

* Chksum check
Checks if "immutable" data (log-entries and old revisions) are
currupted. Might or might not react at outdated (deleted) revisions.

(the chksumtst command as used above is ment to first check, then export)

* Exporting backup files (as in "rawbackup" above)
Creates a differential file containing data that might be used to
update the ,v-files.

* Importing backup files (as in "restorebackup" above)
Reads files of the format above, and builds an up-to-date repository

My idea is to either stream compressed backup files to a proper
storage media (like a tape), or to have a backup CVS repository (at a
backup server or at another disk) - or both. A backup/mirror cvs
pserver should never allow anything else than importing backup

The concept having a backup repository might also be used to provide
mirroring of CVS-sites. The mirrors would be read-only, though. The
concept could however be extended to a truely distributed, global CVS
environment. In a truely distributed, global CVS environment each cvs
server would have a repository of projects beeing followed locally -
and the development in the repository would be a local branch. At
regular intervals, the branches should be merged with neighbouring CVS

* Undo outdates (deletements) of old revisions

The usefulness of this command is obvious in a distributed environment
- we like to have some of the advantages by having a repository
locally, but we don't want to pay the price regarding disk space, so
we keep outdating anything but the latest versions of the files. But
suddently we'd really like to have revision 1.14 anyway.

TobiX                   In a world without fences, who needs gates?

2. work around ksh feature in other shells

3. current CVS tree vs released CVS tree

4. DNS Doesn't want to work

5. CVS - Not really FreeBSD, but I expect a few FreeBSD users are familiar with CVS !

6. BK Changeset 1.615 - Makefile fix breaks i386...

7. cvs 1.3 BUG: cvs ci -r after a higher ci...

8. Free TTF helvetica fonts ?

9. CVS server timeouts - what ports does cvs use?

10. Samba- Problem: path too long/ cvs- Problem: cvs import stucks

11. CVS repository for common files

12. CVS repository over ftp?

13. What is CVS Repository ??