Multisite

This page discusses how to handle CVS when developers are separated by geographical and/or organizational dispersal.

First, consider the option of having one master repository and all developers interacting directly with it using client/server CVS as needed. While this may be inconvenientand may not do enough to isolate one group's work from the others, it ensures 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.

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 (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.

This section focuses on enhancements to CVS which might help with multisite issues.

One Site per Developer?

Here are some ideas about making sites lightweight. In the limiting case, each developer would have one (or more) sites.

• It should be possible to create and maintain a "site" (branch, basically) in a lightweight way. For example, some projects will prefer one or more site per developer so that developers can easily try out experimental changes and then later merge them into the main sources with the tool being able to help with this. Another example is using CVS to maintain configuration files across a set of similar but not identical machines, with one site per machine.
• One simple design goes something like this: (1) there is a "populate" command which copies the RCS files from the CVS repository into RCS/foo,v files in the working directory and also notes the head revision in CVS/VersEnt; (2) hack away using standard RCS commands; (3) there is a checkin command which walks the working directory looking for files in which RCS/foo,v has newer revisions than CVS/VersEnt. If so, check them in (for example, use the existing protocol to check in one revision at a time). If an up-to-date check fails, provide some convenient way to create a branch (and then do "update -j" or the moral equivalent). Or something like that.
• By getting rid of CVS/VersEnt and making the "checkin" command more fancy, one could use this on trees which were not initially created by the "populate" command but instead had their RCS files copied by some random mechanism at some point in the past. This is a fairly fundamental shift in the design.

Master/Slave Ideas

The basic master/slave idea, as described above is that checkins happen at the master and slaves are updated via CVSup (or your favorite tool for this). This works great provided the users are divided into people who only look at the sources (who access the slaves), and a relatively small number of people who check in (who access the master directly).

Now, what if you want a given person to be able to run "cvs update" from a slave and "cvs ci" to the master?

• If they get an "up to date check failed", the situation is more subtle than it may seem, because their slave may not have the most up to date revision yet. I think the solution is probably to run CVSup, or whatever the tool is, for the files that have changed only, each time someone checks something in to the master (see Keeping a Checked Out Copy which has some generally analogous scripts/ideas).
• Would like some kind of extension to CVS to use one root for updates and another for checkins. I suppose you could ask people to specify the -d option when they do a checkin, if one wanted to go with the really bare-bones version.
• As an alternative to the above idea, the server being used on the slave sites could be modified somehow to forward checkins to the master. The current protocol/implementation doesn't really facilitate this but that doesn't mean it is impossible.
• Would want to think about commands which change existing revisions (cvs admin, cvs tag -d, &c).

• Another multisite tool is the freely distributed 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).
• 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).