Unique Photo CVS Cheat Sheet

Prepared by: Mike West November 11, 2009.

This is really a quick shorthand for the installation on dar.uniquephoto.com that is checked out to asweet and is mostly directed for his use there. However, this is still a pretty good down and dirty intro to Version Control, and how we're using it. The aim of this document is to prescribe the correct Workflow, and, in subsequent sections, to show CVS in action in more detail.


This workflow applies to pretty much any CVS installation of any kind – indeed any Source Control system of any flavor. It certainly applies to our Magento installations, our FACTS installations, our credit card implementations, etc. These concepts become habit, second nature. Done properly, the system does everything for you: maintains a history of changes, eliminates unnecessary backups of files, maintains accountability of Who did What When. Debugging is immeasurably simpler, because you can compare any version of a file to any other version.

This is the workflow; follow this workflow and you can never go far wrong.

  1. Check out files (already done on dar.uniquephoto.com)
  2. Work, work, work.
  3. Check for updates to your file (cvs status yourfile).
  4. Update if necessary (cvs update yourfile)
  5. Resolve conflicts if necessary (that is, go to step 2)
  6. Review changes (cvs diff yourfile)
  7. Commit changes (cvs commit yourfile)

General Concepts

The important general concepts are:

  • The Repository: Store the files and the history of a given project.

  • Working Copy: Your local version of the project

  • CVS Commands: The commands you use to check out files, commit (return to repository) and check that status of files.


We have a central Repository of "Golden Code" that is stored on spartacus.uniquephoto.com and backed up every night. You can peruse that source here: CVS Repository

For example, FACTS was originally imported 4+ years ago. Any change ever made by me or Dave over the last 4 years is there, commented and documented. You can also use the command line "cvsps" in any source-control'd directory to get the history of that directory for all time. Try this on johnny5 in /u/ssi6/mods/prog/SO.src. This history of changes to those programs runs some 6,481 lines!

Working Copy

Since it's typically been only me or Dave, we've kind of adopted a lax "Working Copy" policy, but we're tightening that up now. Generally, every person has their own working copy. My working copy of magento, for example, is on johnny5.uniquephoto.com at /magento. Alexander's working copy is on dar.uniquephoto.comthat's right, on our remote system.

CVS Commands

Checking Out: cvs co

This gets you a working copy of the current project. For dar.uniquephoto.com, this has already been done.
cvs co path/to/repository/project

Checking for Updates: cvs status

While you're working, the ideal situation is everyone else is working too! This means someone might have made changes while you were making your changes. So, you can issue a cvs status against your file (or entire Working Copy). 
cvs status someFile.php
Here's a real life example. Out on dar.uniquephoto.com, boxes.css is changed. However, cvs status tells us that the repository has changed since we got our working copy out:

dar@dar.uniquephoto.com [~/public_html/e/skin/frontend/uPhoto/uBasen/css]# cvs status boxes.css
File: boxes.css         Status: Needs Merge

   Working revision: 1.8
   Repository revision: 1.13 /home/cvsroot/magento/skin/frontend/uPhoto/uBasen/css/boxes.css,v
   Sticky Tag: (none)
   Sticky Date: (none)
   Sticky Options: (none)
You can safely ignore the "Sticky" stuff – we're not sophisticated enough to use that yet. (And by the time we are sophisticated enough, we'll be switched to git Source Control anyway). This tells you that boxes.css is 5 revisions ahead of your working copy! Notice that status says "Needs Merge." What do we do? We update!

Merging Changes into Your Working Copy: cvs update

OK, boxes.css has been altered since our last update. Let's update again:

dar@dar.uniquephoto.com [~/public_html/e/skin/frontend/uPhoto/uBasen/css]# cvs update boxes.css
RCS file: /home/cvsroot/magento/skin/frontend/uPhoto/uBasen/css/boxes.css,v
retrieving revision 1.8
retrieving revision 1.13
Merging differences between 1.8 and 1.13 into boxes.css
rcsmerge: warning: conflicts during merge
cvs update: conflicts found in boxes.css
C boxes.css
Oh Oh. Houston, we have a problem. CVS is telling us that if found "conflicts during merge." This means that changes we have made conflict with changes someone else made, and CVS can't figure out what to do about it. Problem? Nope, not at all. All we have to do is edit boxes.css again, and look for the conflicts, which CVS conveniently marks for us with leading <<< and >>>.

What have You Changed? cvs diff

After fixing our conflicts in the update, we now set about doing the actual editing we came here to do. So, asweet makes some changes to boxes.css. What were those changes? cvs diff tells us:

dar@dar.uniquephoto.com [~/public_html/e/skin/frontend/uPhoto/uBasen/css]# cvs diff boxes.css 
Index: boxes.css
RCS file: /home/cvsroot/magento/skin/frontend/uPhoto/uBasen/css/boxes.css,v
retrieving revision 1.13
diff -r1.13 boxes.css
<     border:1px solid #666666;
<     font:bold 12px arial, sans-serif !important;
>     border:2px solid #666666;
>     font:bold 14px times, serif !important;

The "<" means "this was in the repository version" and the ">" means "this is the change that was made." In this case around line 94, we changed the border size, and made the font larger and serif.
It is good practice to test your changes, and thoroughly review them before you commit code back to the repository. Which is what well do next.

Committing Your Changes back to the Repository: cvs commit

You're happy with your changes. You've tested them, and you've run a diff and reviewed what you changed just once more. You're ready to commit this change to the repository.

dar@dar.uniquephoto.com [~/public_html/e/skin/frontend/uPhoto/uBasen/css]# cvs commit boxes.css

An editor will come up and ask you to comment on your changes (which editor depends upon your environment. Remotely, it defaults to nano.) The comment I added here starts with an '*'. The '*' is totally superfluous, I don't know why I do that. Maybe it's for legibility on multiple changes? It's an old habit.

GNU nano 1.3.12                 File: /tmp/cvstembP3               Modified  

* Made the Add to Cart Button's font larger with a thicker border.
CVS: ———————————————————————-
CVS: Enter Log.  Lines beginning with `CVS:' are removed automatically
CVS: Committing in .
CVS: Modified Files:
CVS:    boxes.css
CVS: ———————————————————————-

Now save those comments and exit the editor, however the editor wants you to save). In nano, it's Ctrl-O, <ENTER> and then Ctrl-X.

After saving the comments, cvs will report the result of your commit:

Checking in boxes.css;
/home/cvsroot/magento/skin/frontend/uPhoto/uBasen/css/boxes.css,v  <–  boxes.css
new revision: 1.14; previous revision: 1.13

Updating the Live Site: cvs update

Yup, that's it. Just sign in to the Live Site, go to the appropriate directory and run cvs update on the file you changed. The Live Site is simply another "Working Copy" that we all agree is only updated by CVS, and never by human hands.