In Sync with CVS
by James Duncan Davidson
07/15/2003
The scenario: Instead of just using one Mac, you regularly use two (a
desktop and a laptop) and would like to keep up to date copies of your
data on all of your machines. After all, when working at home, you want to
take advantage of the large monitor and dual processors of a desktop
PowerMac, and when you are on the road, you want all the portability of an
iBook or a PowerBook.
Most homemade solutions to this problem are haphazard and error
prone. However, there is a tool that software developers use that can help
you. It's called CVS. And with it, you can work with your data no matter
where you are.
What is CVS?
CVS is an open source tool that provides version control. Version
control is the practice of maintaining information about a project's
development by tracking changes and coordinating the development efforts
of many developers. CVS uses a centralized repository (sometimes called an
archive or a depot) to store all the information about each and every
file, as well as every change to those files, contained in a
project. These kinds of systems are used in the development of projects
small and large, including the development of operating systems like Mac
OS X.
When using version control, each and every developer of the project has
a copy of these files on his or her own machine. As a developer makes
changes, they are committed back into the central repository allowing the
other developers on the project access to the latest code. This allows
lots of people to cooperate on the same source files with a minimum of
fuss. If two developers make changes to the same file at the same time,
CVS will defer the commit of the second file until the second developer
resolves the conflict. Usually, these conflicts are easily dealt with and
development proceeds.
CVS supports all sorts of additional operations that are useful to
large teams. However, for our purposes (which are much less demanding than
software development), we can take the functionality that we've just
described and use it to solve the problem of managing our own data on
multiple machines. Even if you are the only person to use your data, CVS
can help you easily maintain it on as many machines as your bank account
can fund.
CVS comes as part of Mac OS X's development tools. In order to use it,
you'll need to install the developer tools. You can find the tools on the
Tools CD-ROM that came with your copy of Mac OS X or you can download them
from the Apple Developer
Connection. Of course, you could get the source for CVS and compile it
yourself, but then you'd need GCC. Just save yourself the hassle and get
the developer tools.
Using CVS
First, you need to identify a machine that can serve as the
repository. If you have two machines, such as an iBook and a PowerMac,
then you should choose the one that stays at home and powered on, in this
case the PowerMac, as your repository. If you are lucky enough to have a
third machine that you use as a server for other purposes, then you should
probably use that machine to store your repository on. The important thing
is that the machine you use as a server should be one that is likely to be
powered up and available when you need it.
Once the repository is set up, you can access it from the machine you
set it up on or from other machines. The first case, where both the
repository and the working copy of your files are, is an example of local
usage. The second case, for example, when you check out your files onto
your iBook, is called remote usage. In both situations, you use the same
set of CVS commands, but you have to do a bit more set up work for the
remote case.
Creating the Repository
Once you've decided on which machine to place the repository, you have
to pick where on that machine you want your repository to live. You want
to make sure that it is a location that you'll remember easily later. For
my setup, I use the /Library/Depot directory. Once you've
decided where you want it, create the directory, then initialize your
repository with the following commands:
[Mercury ~] duncan% mkdir /Library/Depot
[Mercury ~] duncan% cvs -d /Library/Depot init
The -d argument lets CVS know where the repository is
located. The init argument tells CVS to initialize the
directory as a new repository. This blesses the directory as a CVS
repository and installs a copy of the files that will control how it
works.
The First Checkout
To make sure all is well, we are going to perform an initial checkout
of the repository. Make an empty directory (on the same machine as the
repository) and execute the following command in that directory:
[Mercury ~/tmp] duncan% cvs -d /Library/Depot checkout .
Once again, the -d argument lets CVS know what directory
the repository is located in. The checkout . argument
(don't forget the dot at the end!) tells CVS to checkout a copy of
everything in the repository. You should see the following output from
CVS:
cvs checkout: Updating .
cvs checkout: Updating CVSROOT
U CVSROOT/checkoutlist
U CVSROOT/commitinfo
U CVSROOT/config
U CVSROOT/cvswrappers
U CVSROOT/editinfo
U CVSROOT/loginfo
U CVSROOT/modules
U CVSROOT/notify
U CVSROOT/rcsinfo
U CVSROOT/taginfo
U CVSROOT/verifymsg
The files that were checked out are the administration files. By
editing, and then checking these files back in, we can change how CVS
works. Mostly, we will want to leave these alone for our use, but there is
one file that we will need to modify.
[1] [2] [3] Next