Identifying Binary Files
In addition to several quirks, CVS has one major flaw. By default it treats all files as text files and can't, by itself, tell the difference between text and binary. It wants to treat all files as text because then it can save space in the repository by only storing the difference between files. For HTML files, this is great. However, for binary files that we work with all the time, such as Microsoft Word files (.doc) or Excel files (.xls), this strategy falls on its face and will make a mess.
To fix this, edit the
CVSROOT/cvswrappers file to look
like the following (the lines you need to add are in bold):
# This file affects handling of files based on their names. # # The -t/-f options allow one to treat directories of files # as a single file, or to transform a file in other ways on # its way in and out of CVS. # # The -m option specifies whether CVS attempts to merge files. # # The -k option specifies keyword expansion (e.g. -kb for binary). # # Format of wrapper file ($CVSROOT/CVSROOT/cvswrappers or .cvswrappers) # # wildcard [option value][option value]... # # where option is one of # -f from cvs filter value: path to filter # -t to cvs filter value: path to filter # -m update methodology value: MERGE or COPY # -k expansion mode value: b, o, kkv, &c # # and value is a single-quote delimited value. # *.ai -k 'b' *.doc -k 'b' *.bmp -k 'b' *.class -k 'b' *.classes -k 'b' *.dmg -k 'b' *.eps -k 'b' *.gif -k 'b' *.gz -k 'b' *.icns -k 'b' *.jar -k 'b' *.jpg -k 'b' *.jpeg -k 'b' *.nib -k 'b' *.ofile -k 'b' *.pdf -k 'b' *.png -k 'b' *.ppm -k 'b' *.ppt -k 'b' *.pqg -k 'b' *.prj -k 'b' *.ps -k 'b' *.psd -k 'b' *.tar -k 'b' *.tif -k 'b' *.tiff -k 'b' *.ttf -k 'b' *.xls -k 'b' *.Z -k 'b' *.zip -k 'b'
This is not an exhaustive list, but it serves as the day-to-day list that I use in my repository. Make sure that any binary files that you will put in your repository are on this list. Note that the file is case sensitive so you may want capital versions as well.
Once you have edited the file, we need to check it back in. To do this, issue the following command:
[Mercury ~/tmp] duncan% cvs commit -m "Sync"
This tells CVS to commit our changes back to the repository. The -m argument is the commit message that will be kept in the repository. When you execute this command, you should see the following output:
cvs commit: Examining . cvs commit: Examining CVSROOT Checking in CVSROOT/cvswrappers; /Library/Depot/CVSROOT/cvswrappers,v <-- cvswrappers new revision: 1.2; previous revision: 1.1 done cvs commit: Rebuilding administrative file database
This output will tell you each and every action that is taken by CVS. In this case, it notices that we've modified one of the configuration files and rebuilds its administrative database.
You might notice that we didn't use the -d argument to CVS this time. We only need to tell CVS where the repository is if we haven't checked it out yet into the directory that we are working in. Once checked out, CVS leaves itself enough information to figure things out.
Checking Out on Remote Machines
To checkout a repository on other machines, we are going to use the ability to run CVS over SSH. This requires two things:
The SSH server is up and running on the machine on which the repository is located.
CVS_RSHenvironment variable is set on the client machine on which we are going to checkout the repository.
To satisfy the first requirement, simply enable the Remote Login Service option in the Sharing preference panel, as show in Figure 1.
This enables the SSH server on your machine which will let you login to your machine from any other machine that has an SSH client.
There are a few different ways you can satisfy the second requirement. You can set the environment variable on the command line with the setenv command. To do this, simply execute the following line:
[Titanium ~/tmp] duncan% setenv CVS_RSH ssh
Of course this will soon become annoying, as you'll always have to
remember to execute this command. You could always set it in your
~/.tcshrc file, but there's an even better solution. You can
set it in your ~/.MacOSX/environment.plist file. This will
make sure that it is set for every application that runs allowing programs
that have built in CVS integration, such as Project Builder, to seamlessly
use your repository. All you need to do is create the
~/.MacOSX directory (if it doesn't exist), and save the
following as your
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist SYSTEM "file://localhost/System/Library/DTDs/PropertyList.dtd"> <plist version="0.9"> <dict> <key>CVS_RSH</key> <string>/usr/bin/ssh</string> </dict> </plist>
This is by far the best solution, although you'll need to log out of your machine and back in for it to take effect. Once you've done this, you're ready to check out the repository. To so do, we're going to use a variant of the cvs checkout command that we used before that will tell CVS that our repository is located on a different machine. This command is of the form:
cvs -d :ext:[user]@[machine]:[repository directory] checkout
On my machine, I execute the following
[Titanium ~/tmp] duncan% cvs -d :ext:duncan@Mercury.local:/Library/Depot checkout .
Once again, don't forget the dot at the end! If this is the first time that you've used SSH between your machines, you'll see some output asking if you are sure you want to connect. You will then be challenged for your password for the machine containing the repository. After that, the files will be checked out as before.
There is another way to remotely access a CVS repository (called pserver access), but it is more difficult to set up and not as secure for our purposes. If you really want to set up this kind of access, there is information on how to do it in many of the CVS books.