The cvslock (1) program is used to safely manipulate and inspect CVS
repositories; to this end, it properly uses CVS' lock file mechanism.

The primary application for which this program was created was
keeping several instances of the same CVS repository in synch; using
CVSup which apparently does a superior task at this was not an
option in my precise application.

My method to keep repositories in sync relies on rsync and ssh for
the "transport proper"; cvslock is wrapped around them in an
appropriate fashion.  The direction I'm using is an upload;
downloading files should be similar.  

I'll call the site from which code is being uploaded the master,
while the upload target host is the slave.

1. Master side locking: Here, we simply invoke the following
   command:

   cvslock -R -d <local root> -c <command> <package>

   This will generate a read lock on <package> and invoke <command>.
   <command> will typically be rsync, e.g. something like

   rsync --exclude '#*' -av mutt/ sigtrap:/home/roessler/cvs/mutt

2. On the slave host, the rsync "server" must run inside a cvslock
   wrapper.  

   This is the cvslssh script's job: It takes the remote server
   root, CVS root, and package name as command line parameters. They
   are then followed by the remote host name and the remaining
   rsh/ssh command line parameters.  The script takes these
   parameters and executes the following command:
   
   ssh $host cvslock -q -W -d $remote_root -c "$command" $package
   
   For rsync's purposes, it can be used as a drop-in replacement for
   ssh.  E.g., I'm using the following RSYNC_RSH setting for
   carrying my repositories around:

   "/home/roessler/bin/cvslssh /var/tmp/cvsroot.tmp/ mutt"

Please report any bugs and improvements about this to
<roessler@guug.de>.

$Id: README,v 1.2 1998/10/19 19:25:32 roessler Exp $
