Re: Multisite CVS

[Kaz Kylheku]

On Thu, 7 Nov 2002 address@hidden wrote:

> Couldn't you use something like CVSup and automatically trigger its
> execution after every check in?
> Is there more to a multisite repository than meets the eye?

There is more. What happens in distributed development is that people
work on their own local stream; the other sites get some kind of
patches that they have to integrate. Support for changesets can help
with this, but you can't get around the requirement that there will
have to be merges. Moreover, since you want everyone to end up with the
same code, there has to be sufficiently frequent backpropagation of the
integrated material.

A version control tool with good third party source tracking can be
used to implement a half-decent distributed process. 

You can have one ``master'' repository where all of the inputs from all
the development teams are integrated.  The teams work with their own
repositories. The master repository gets code snapshots, tracks them
using individual third-party branches, and merges them into the
main trunk. Every once in a while, the disconnected developers have to
synchronize by getting a snapshot of the main trunk, which they can
track on their own third-party branch.

After such a synchronization, the master repository can start a new
branch for each synchronized team. If you synchronize with
``release-1-3'' from the master repository, then your next piece of
work will be a derivative of that baseline; the master repository acn
start a new branch for capturing your input, shooting from release-1-3,
rather than continuing with your old branch, which would then capture
extraneous differences arising from the backpropagation.

CVS has something called ``vendor branching'', but it can't handle
these requirements. Using regular CVS branches in this way involves
a whole lot of error-prone manual labor. <plug>Meta-CVS, on the other
hand, has more advanced third-party tracking which can implement the
above model using a few simple commands.</plug>

The nice thing about this model is that the teams can implement
whatever local process they want, using whatever tools they are
comfortable with. All that the master repository keepers need from a
team is a code snapshot.  (Under Meta-CVS, that snapshot can, relative to
the previous snapshot, contain adds, removes, renames, execute
permission changes and reconfigurations of symbolic links; these
changes are automatically figured out).

The disadvantage of this process is that detailed commit history is
lost, because the inputs to the master repository are just snapshots.
This problem can be partially alleviated if people maintain a detailed
ChangeLog type file.  Version control tools that support changesets
take care of propagating such change details. But on the downside, they
require everyone to use them; the individual teams have to produce a
changeset that the master repository understands.