Native CVS on Mac OS X 10.8

One might ask, why are we using CVS? Faster, more efficient and wieldy version control systems exist, like SVN and GIT, each with quicker setup and user-friendly graphic interfaces. In a similar vein, we could also ask “Why do we work, when we could just do whatever we wanted all day?” or, “Why is this night different from other nights?”

Unfortunately, the equipement we’re asked to use sometimes makes choices for us. But regardless of your feelings concerning CVS, this should make it easier to install the tool on a late model Mac running Snow Leopard to Mountain Lion. Wouldn’t you prefer to only run this each time you commit?

$ cvsbeta components/* wrappers/index.jsp

This guide is aimed at those of y’all who have local admin rights and are relatively comfortable working in the command line (Terminal, Bash, you know what I’m talking about). If you’re not, sorry, you’ll still have to use a graphic interface like WinCVS in a Windows virtual machine. If you’re feeling game, here we go!

Install Xcode

Xcode is Apple’s development environment for OS X and iOS, and includes tools, simulators, and the latest SDKs. If you haven’t already installed it for another reason, do it now. We’ll need this for a few reasons, but primarily so we can compile. You can get your free copy in the App Store, or on Apple’s website.

We’ll also need the command line tools add-on for xcode, so we can run some sweet, sweet commands in Terminal.

Install Fink

The nice folks at the Fink Project “modify Unix software so that it compiles and runs on Mac OS X (‘port’ it) and make it available for download as a coherent distribution.” Gentlemen and scholars, all of them.

Careful, the directions on their download and install instructions page might be a little hairy for those who aren’t comfortable using Terminal.

At some point in the Fink installation, you will most likely be be prompted to install XQuartz. Go ahead. It won’t hurt anything, and it provides X11, which is not included with Mountain Lion.

Once Fink is in, you should be able to test if CVS is set up by running a simple command like the following in Terminal:

$ cvs up

Saving Time

If you’re always going to be working off the same CVS server, you can set your CVSROOT by adding the following lines to .profile in your home directory:

CVSROOT=:pserver:USERNAME:PASSWORD@DOMAIN.COM/CVSROOT_DIRECTORY
export CVSROOT

Shell scripts are also very handy time-savers, if you’re feeling especially empowered. I use the following to commit all files listed after a “cvsb” command, then tag them BETA and QA, so CVS will push them into those environments. Then we iterate through the variable arguments with “while” and “shift” to let us know all is well. Just drop this guy into /usr/local/bin, run “$ chmod +x cvsb” and call it a day. Caution: if you don’t know what you’re doing, don’t screw around with /bin.

cvs ci -m '' $@
cvs tag -F BETA $@
cvs tag -F QA $@
echo ""
echo "Committed and tagged BETA and QA:"
while [ $# -ne 0 ]
	do
		ABPATH=$(pwd "$1")
		echo "$ABPATH/$1"
		shift
done
exit 0

So, if you’ve gotten this far, and everything has worked according to plan, you can open Terminal and just type this simple command to commit and publish.

$ cvsb filename.html

CVSIgnore is another good way to speed up your workflow, even if it’s just a little bit. Just create a file named .cvsignore in your user’s home directory, and add patterns that you want CVS to never check. Ignoring files like .DS_Store will make the cvs update command a little faster, and printouts a little easier to read. Learn more here.

Good luck, and happy developing!