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.

NFL Week 12 Picks

Welcome to a Childress-Free Week 12!

Chilly’s gone, and I imagine Brett’s … happy? So happy, in fact, that he apparently got sick and may have pneumonia. I just got vaccinated against pneumonia. Apparently I have a better doctor than Brett.

Still, Brett doesn’t have Brad to blame any more. Neither does the rest of the team.

The Only Problem Brett Favre Has

They had a “dysfunctional” locker room. Dunno how this helps them on the field, but we’ll see. The only problem Brett has left is the sexting or whatever the hell was going on with Jenn Sterger.


  • WASHINGTON -2 over Minnesota. Brett Favre “might” have “pneumonia.” Minnesota “stinks.” The Vikes are 0-5 on the road and have yet to cover. Why start now?
  • Pittsburgh -6½ over Buffalo. The Bills’ 2 Game Win Streak ends today I think.
  • HOUSTON -5½ over Tennessee. Let the Rusty Smith Era Begin!
  • Jacksonville +7½ over NY GIANTS. Whoa. How are the Giants 7½ point favorites over anyone, anywhere, when they turn the ball over like that? Plus I think both teams want revenge against Tom Coughlin.
  • CLEVELAND -9 over Carolina. In consideration of Panther fan, I don’t have the heart to look up the last time the Browns were 9 point favorites.
  • Green Bay +1½ over ATLANTA. Atlanta has to lose at home some time, why not now? This week’s GAME OF THE CENTURY!


  • Tampa Bay +7½ over BALTIMORE. I’m not convinced either team can score 7½ points, so I’ll take the underdog.
  • OAKLAND -3 over Miami. I feel bad for Miami, but it’s their own damn fault they haven’t had a quarterback in over a decade.
  • Kansas City -2 over SEATTLE. Either Seattle’s a fraud or Kansas City is. Possibly both.
  • St. Louis +3½ over DENVER. The Rams are going to win a road game, I just know it!
  • Philadelphia -3 over CHICAGO. As a true Philadelphian, I am simply waiting for the Other Shoe to drop and watch a completely miserable Eagles game. On the other hand, this is the Bears and Jay Cutler we’re talking about here. The line moved ½ point in the Bears direction during the week.

Sunday Night

  • INDIANAPOLIS -2 over San Diego. Teams somehow, sometimes, just find ways to win when they really shouldn’t.

Monday Night

  • ARIZONA +1 over San Franciso. What is the point of Flex Scheduling if you can’t move a stinker like this one? Eh, I have a couple episodes of “Fringe” DVR’d.

Web 2.0 Expo: Sudden thoughts and Second Thoughts (with apologies to Bill Lyons)

I am returned from the Web 2.0 Expo. Floor only pass, I didn’t get to attend anything else, but I did buy two books.

Sudden thought: wow, does web 2.0 ever need a lot of hardware. Sure, Internet connections are fast, but the things you connect to better be fast as well. Lots of hardware vendors here. Lots.

Sudden thought: this all sounds like Deja Vu all over again. Lots of people touting technology that helps you build apps,  connect to your community, block spam (what?? Who blocks spam these days? Why aren’t you using Gmail or *gasp* yahoo! mail??), monitor network traffic (who runs their own network? Ugh I forgot – I do), or check out who’s latching onto your Wi-Fi.

So half the hall – no, wait, 66% of the hall – is dedicated to the people who bring you the hardware, the Raw Materials, as it were, of Web 2.0.  23.3% (unofficial tally) were … exactly all the same offerings. Community web builder blogosphere building blocks enterprise 2.0 (a retronym if there ever was one, considering “enterprise” is in and of itself a weird sort of retroynm).

So it’s 1997 all over again. Clearly something is happening, but what? I really do think something is happening, but … well … what? flickr is a terrific example leading off a (so far) excellent text Web 2.0: A Strategy Guide (by Amy Shuen, O’Reilly Press), but how do I make money? How do I build a community of photographers who… well, what are they doing? How can I tell? How do I know? We sell all manner of terrific photographic equipment, but how do I get the message out?

How do I build a sincere community around photography, purchasing from my store – at fair prices, mind you – without some … what? Do I need a go-to gadget?

Or do I need to tie together what they’re doing elsewhere with my own special brand of ability (i.e., mashups with some APIs and relationships with product manufacturers like Nikon, Canon, Fuji, etc)? Hmm. What do you think?

Oh, and apologies to Bill Lyons, of the Philadelphia Inquirer, because he used to have a column called “Sudden thoughts and second thoughts.” To be fair, though, he never did send me a copy of his Jeremy Roenick article, circa Jeremy’s rookie year, about how tough the NHL playoffs are. Maybe this can spark him to find a publisher, because BL should definitely have a book – in specific for Philadelphia Sports Fans, but in general for readers everywhere. The man can write.

But what can I do?