December 14, 2011

How I Use Surround SCM: A User Interface Tour

Surround SCM
The very first release of Surround SCM happened in September 2002. I've been using Surround SCM since July of 2002. Pretty neat trick huh? The reason, of course, is because I've worked at Seapine since before Surround SCM released and we dogfooded our own product before we offered it to the world. That means I've been using Surround SCM as a developer for something coming close to ten full years. [caption id="attachment_10459" align="alignnone" width="371" caption="Original Surround SCM splash screen"][/caption] Being such a long-time user, I thought it would be interesting to take a walk around Surround SCM and share how I like to use it and how I have it set up. This first post will deal with the GUI client but future posts will include things like the command line interface, changelists, and maybe—if you are really lucky—a bit about continuous integration. First things first, here's a screenshot of my typical client. In this case you can see the source listing for the Qt framework that we use as the basis of our UI. [caption id="attachment_10462" align="alignnone" width="450" caption="Screenshot of my typical client (click to zoom)"][/caption] From this top-level view, I'll highlight a few things.
  1. I much prefer using the Branch drop-down to change between branches rather than showing the branch pane all the time
  2. My toolbar is customized to the operations I use the most often
  3. I always work in a single document interface (SDI) mode
Speaking of my toolbar, here's a slightly bigger version of it: [caption id="attachment_10466" align="alignnone" width="620" caption="My toolbar, many are like it but this one is mine"][/caption] I use the Get, Check In, History, Differences, and View File commands every single day when I am developing. I honestly don't use Check Out and Undo Check Out as much as I used to because I prefer to follow the Edit-Merge-Commit model instead of the Check Out-Edit-Check In one. These commands do come in handy when I want to add graffiti or mustaches to our graphics files while our graphic designers aren't looking. Info is just a way to bring up more detailed information, like the date added or who owns the file, about what I've got selected. I paste links into the Address field several times a day when I'm talking to other developers through  instant messages or email. Finally, the Annotate button is the one I click while praying that I didn't actually write a section of really weird code that I've stumbled across. Next stop is the Filter and Search toolbar. We have a whole bunch of source code, just like everyone else. I have something like a dozen filters that I've set up to cut down the list of files in to something a lot more manageable. Out of all them, I use the "Files That Are Not Current" filter the most because it shows me all the changes that I've made. From this filtered list, I can do diffs before I check in as a last second self-code review in the hopes that someday someone doesn't have to use Annotate while mumbling, "What in the world was someone doing here? Oh great, Lammi committed that." I don't use Filename Search all that often but it does come in handy when I just want to see all the .png files without creating a filter. (Remember, graffiti and mustaches.) Last but not least are the source files themselves. [caption id="attachment_10473" align="alignnone" width="395" caption="The actual list of source code"][/caption] Compared to a lot of the other developers at Seapine, the columns that I choose to display are pretty spartan. I'm really only concerned with the name of the file, its status, and the last time it was changed. The Version column is useful because it gives me a hint about the maturity of a file. For instance, the higher the version number, the more times it has changed. If I'm working on something and I see a big number in the Version column, I'm much more likely to do a History or an Annotate command to see what is going on with the file. That's it—that is my daily Surround SCM setup and it has been pretty much that way for ten years. Stay tuned for more posts about how I use individual commands and other things in my workflow. I'll leave with one fun fact to close things out. I ran a report against our database to see how many actions I have performed on files in our oldest development mainline. The answer: 822,384 and counting. Here's a look at number 822,384...