This area is an archive and is no longer actively maintained. Information found on this page is likely to be extremely out of date and therefore highly inaccurate. We recommend the Ximbiot - CVS Wiki for up-to-date information about CVS and its associtated tools.

If you do find anything useful on this page that is not yet in the Ximbiot - CVS Wiki and you have the time, please add it!

CVS Multisite

CVS Multisite

Many people wonder how to handle CVS when you have developers who are separated by geographical and/or organizational dispersal. This page focuses on short-term solutions using existing tools; if you are wondering more about various ways CVS might be enhanced, see our Development of CVS: Multisite page.

  • First of all, you should at least consider the option of having one master repository and having all developers interact directly with it, using client/server CVS as needed. While this may be inconvenient in the case of flaky networks, and may not do enough to isolate one group's work from the others, having all developers work from a master repository is the way to ensure that merges happen quickly and are done by the developers while they are working on the code to be merged. Doing merges later is not necessarily bad, but do be aware of this tradeoff. Don't dismiss one master repository; this is what Mozilla does and they have quite a few developers and lots of activity.
  • If the main concern is flaky networks, and/or distributing the load among various CVS servers, you probably want one master repository, where all the checkins occur, and slave repositories. Using a general-purpose mirroring tool like rsync or rdist will generally work in practice (to avoid possible inconsistencies, use them in conjunction with the cvslock program from Thomas Roessler). The CVSup tool also can help with mirroring.
  • If the main concern is allowing loosely coordinated teams to pass code back and forth, CVS's vendor branches are designed to help with this situation. They don't do everything that one might hope for (for example, adding and removing files, and tracking what is included in different releases can be a bit more difficult). However, vendor branches are a good place to start.

For More Information

Another multisite tool is sync_update from William A. Hoffman. This is similar to vendor branches, in the sense that one passes back and forth checked out files, rather than revisions (with log messages, revision numbers, &c). The sync_update tool is freely redistributable.

OpenBSD has a fairly extensive mirroring setup, and a web page describing it. The mirrors use the "sup" mirroring tool (a relative of CVSup) to get their sources from the master (as nearly as I could tell).

Another tool, similar in general terms to vendor branches, is cvs-track. The license (which would seem to almost, but not quite, conform to the Debian Free Software Guidelines) is:

# This program may be freely redistributed and modified as long as you
# meet these conditions:
# It must retain the copyright message and terms in unmodified form.
# If you modify it and distribute it, you must clearly mark any modifications,
# and make a copy available to the author

[Cyclic Home]

Derek Price, CVS developer and technical editor of Essential CVS (Essentials line from O'Reilly Press) , and others offer consulting services and training through Ximbiot.