oreilly.comSafari Books Online.Conferences.


AddThis Social Bookmark Button

In Sync with CVS
Pages: 1, 2, 3

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
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:

  1. The SSH server is up and running on the machine on which the repository is located.

  2. The CVS_RSH environment 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.

System Preferences screenshot.
Figure 1. Enabling the Remote Login Service option.

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 environment.plist file:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist SYSTEM "file://localhost/System/Library/DTDs/PropertyList.dtd">
<plist version="0.9">

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.

Pages: 1, 2, 3

Next Pagearrow