In Sync with CVSby James Duncan Davidson
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.
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
-d argument lets CVS know where the repository is
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
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 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.