New TestTrack features include a new native relational database, custom fields that calculate values, and draft and active custom fields. Surround SCM’s new features include improved offline support, more flexible mainline branches, and additional integrations, while QA Wizard Pro now features stress testing, Google Chrome support, integration enhancements, and more.

In the one-hour webinar, Paula Rome and Grant Lammi, Seapine product managers, will demonstrate the new features in Seapine ALM 2012. When the demonstration is over, you’ll have time to ask questions and learn more.

The webinar is being offered twice to accommodate Europe and North America attendees. The first webinar begins at 2:00 p.m. Western European Time (9:00 a.m. Eastern Standard Time), and the second will follow at 2:00 p.m. Eastern Standard Time (11:00 a.m. Pacific Standard Time).

Join us!

That, folks, is serendipity.

Penn and Teller

Side note: Years ago I saw a live show of Penn and Teller. And Penn did his juggling broken bottles bit where he takes bottles, typically liquor bottles, then breaks them on stage, and proceeds to juggle their broken remains. This gives a sense of authenticity to the audience as he’s doing something real right before your eyes. He even says something to the effect, “I do this trick all the time, but for real, THIS time these bottles broke in a REALLY difficult way.” That’s classic magician stuff, build the excitement even if the words aren’t true.

How does this relate here you ask? I honest to goodness, cross my heart and hope to die, REALLY did find a regression bug while researching this blog post. For real.

The Surround SCM Track Changes feature is, in a nutshell, a way to quickly determine which branches a specific code change has been promoted or rebased to. You choose the code change either through the revision in a file’s history, or my preference, by the TestTrack issue, a changelist, or a label the code has been associated with.

For our Seapine ALM Reporting Platform product we use InstallAnywhere as the installation technology and, like all our development files, the installer project file is stored in Surround SCM.

When I did a history command on the installer project I noticed this:

It looks like I made some changes to the installer in June on a child branch as the result of a defect, but they were never promoted to the mainline. This was probably because I had already made changes to the installer file on the mainline and didn’t want to clobber those changes.

To make sure, I selected the revision of the file where I attached it to the defect and clicked the Track Changes… button.

Sure enough there is no record of this change in the mainline.

As a quick aside, I could search by changelist, defect, or label by changing the “Track changes for” drop-down selection.

Clicking the Select button while “Defect” is chosen in the drop-down gives me the trusty TestTrack browser dialog where I can use filters and all that good stuff.

See, searching by the defect number, #164, gives me the same result. To completely overuse a magician metaphor, there’s nothing up my sleeve here.

To make sure that I had applied the change to the mainline back in June, I first look at the setting described in the defect for the file on the 2011.1 branch:

A quick look at the 2012 version and I find that it is the exact same uh-oh. I never applied that change to the mainline. This is a regression defect and one that QA will be more than happy to re-open when they find it. I’m not going to give them the satisfaction though.

A quick update to the installer project file and I’m ready to check in, making sure I also attach this check in to defect #164.

If I do a track changes on defect #164 for the mainline branch, I see my change. Note that I don’t see original code change from the 2011.1 branch because that revision was never promoted. However, because I’m using the TestTrack integration and I attached all my changes to the same defect, I can still find everything. (Lesson here, integration is very good.)

So there we go, code check in, regression bug squashed before QA had a chance to find it, blog post written, the only thing left to explain is how Track Changes worked under the covers in the depths of the code. That’s easy.

It’s magic.

1. I refactor and try to get rid of as much code as possible. The less code I write means the less bugs I can write. (Awesome.)
2. I nearly always forget to add new files I’ve created to Surround SCM. (Not awesome.)

At best item #2 means the continuous integration server yells at me. At worst it means one of the other developers yells at me and I need to buy donuts for breaking the build. And I don’t even like donuts.

Some enhancements that are coming in Surround SCM 2012 are tailor-made to help with these two things. First, let’s take a look at what happens when I’ve edited a couple of existing source files and added a new one to the project. I generally do a recursive filter like this before I check in:

This is where I usually get into trouble by forgetting to add new source files. The two files I edited are shown because they’re already in Surround SCM. But I haven’t added the new file yet, so it isn’t listed at all. A better way to see what has changed is to select a parent repository that I am working from and click Differences.

This brings up the Working Directory Differences dialog and, as you can see, not only are my two edited files shown but my brand new file is highlighted in green. Somewhere a donut baker is weeping into his batter at all the lost profits.

All those buttons on the right side of the dialog show actions I can perform. First things first, I can add the new file with the Add button.

All the usual goodness is there, I can add as part of a changelist (which as I’ve written before I always do) and I can attach to TestTrack in case this is all part of bug fix. Same thing applies for checking in the changes to my two edited files with the Check In button.

So that’s all awesome and my coworkers and continuous integration server will be much happier with me. Now, let’s take a quick look at another option on this dialog that helps when refactoring. Let’s say in this case, along with the other changes we’ve talked about before, I’ve renamed a file on my local machine. Surround SCM is tracking that file and has its complete history, but it is tracking it by its old name.

In this example I’ve renamed qttextcode_symbian.cpp to qttextcodec_symbian_deprecated.cpp. My recursive filter, knowing only about the original name and not the new _deprecated name, shows the original file as missing. The Working Directory Differences dialog, however, shows a different story.

You can see that Surround SCM shows that my originally named file is missing locally on my hard drive and my renamed file is missing on the server. If I select both files, the Resolve Missing button becomes active and allows me to choose to either rename the file in Surround SCM or rename it locally on my computer. I choose Rename Server… because I want to rename the file that Surround SCM is tracking.

The Rename File dialog opens, so I can rename the file to its newly refactored name. As always, this is changelist enabled so I can do it all in one big atomic shot.

So pretty cool stuff, but I do a feel a little bad for the local Mason, Ohio economy because of this feature. If you are driving through hit up one of our bakeries and buy a dozen or so donuts. Tell them I sent you and that I’m sorry I haven’t been in lately.

To set options for a mainline branch, right-click the branch in Surround SCM and select “Branch Properties” (or “Branch Info” on Mac). Click the “Options” tab in the Properties dialog box.

Surround SCM mainline branch options

You can override general, changelist, and file name and extension server options for specific mainlines. For example, you can enforce comments on some mainline branches while not requiring comments for others. If you do not configure options for a specific mainline, the mainline options set on the Surround SCM Server are used.

So let’s imagine that I’ve had a defect assigned to me in TestTrack about the user interface of the app I’m working on being choppy under certain situations. The next hour is a flurry of activity, keys are pressed, code is compiled, curses are muttered, and the interns are afraid to approach my desk for fear that I’ll hit them with a copy of K&R.

Note: No interns were harmed in the writing of this blog post.

Note 2: Legal made me say that.

Note 3: It might even be true.

Anyhow, once I’ve got the situation fixed, I need to check this code in so QA will get off my case about it and I can go back to browsing the Internet. A check in is straightforward so I bring it up for the file or files I’ve changed.

Check in Files dialog

The important bit with changelists is that I have to make sure the “Check in as part of the following changelist” option is selected. This is actually a Surround SCM user option so you can have it set up to do this by default every time. (I do.) The drop-down next to it gives you a list of pending changelists that you haven’t committed yet that could be used. For this example I’ll just leave it as <New changelist> to create a new changelist.

Clicking “OK” opens the Name Changelist dialog:

Name Changelist dialog

By default, it is populated with your username and a timestamp of when the changelist was created. You could actually make this anything you want. For example:

“QA is demanding the UI be smooth in animation”

“Man I wish I was reading reddit right now”

“That new intern sure can duck fast”

I use the default value most of the time. However, when I’m fixing a bug, I always click the “Attach to TestTrack…” button. That opens the dialog where I can select the defect I’m working on to attach the code change to:

TestTrack Browser dialog

Let me point out a couple of things about this dialog. First, you not only can attach your code changes to defects but you can also attach them to test cases or requirements too. That’s pretty sweet in and of itself, but I can also apply all my TestTrack filters (like the <Currently Assigned to me> above) to filter the list to into something manageable. If that weren’t enough, I can also view defects/test cases/requirements from here and even add or edit defects from here. This is super handy when you are working on a piece of code, find a bug in that code, and want to create a defect for it as you check in.

Just to prove it, here is the dialog that opens when I click the “View” button. This is TestTrack, with all its fields and graphs and goodies, inside Surround SCM.

View Defect dialog

OK, back to attaching the code to the defect. Clicking the “Attach” button after you’ve selected the right bug gives you even more things you can do…

Attach to TestTrack dialog

…the most important of those being that you can FIX the defect from right inside of Surround SCM. I haven’t opened the TestTrack client once during all of this. I’m not jumping back and forth between apps, I’m just getting things done.

Clicking “Fix…” opens the fix dialog where I leave a little note for QA saying that I’ve saved the day once again.

Fix dialog

After I click “OK”, a new pending event is listed in the Attach dialog. Click “OK” again to return to the changelist.

Event pending dialog

This is the pending changelist dialog, and we are at the last stop on the road.

Pending Changelist dialog

There are loads of things you can do here like diffs, merges, etc. But, I want to commit my changes and mark the defect as fixed, so I click the “Commit Changelist” button. My changes are committed and the defect is marked as fixed in a big shot of atomic goodness.

Now, if you’ll excuse me, there’s a pressing article on ESPN that needs my attention.

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.

Original Surround SCM splash screen

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.

Screenshot of my typical client (click to zoom)

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:

My toolbar, many are like it but this one is mine

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.

The actual list of source code

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…

What’s New?

Following are some of the highlights of this release. More information is available on the beta site.

• TestTrack now includes support for calculated fields, allowing custom fields to automatically calculate their values based on values in other fields. If you use our native backend database rather than an RDBMS, the format has been changed to SQLite, with a variety of performance enhancements. And, to improve the ability to create test cases, we’ve added QA Wizard Pro enhancements that allow you to automatically record and create your test steps.
• For Surround SCM, we’ve improved our support for offline changes with an enhanced working directory differences dialog and a new sync repository command. Mainline branches can also now have separate configurations from your overall server settings, giving  teams more flexibility. We’ve also added a number of new third-party integrations.
• In QA Wizard Pro, we’ve added support for the Google Chrome browser. A whole new set of testing is also now possible with our new stress testing support, allowing you to test applications in stressed conditions that are difficult to create, such as low disk space and memory, network communication problems, and read-only disk errors.

Register for the Seapine ALM 2012 Betas

In this post, Andrew explains how to bind to Surround SCM as the source code provider for an existing project. This example uses one of our sample Visual Studio solutions, Bug Reporter, that is currently bound with Visual SourceSafe, and shows you how to change the binding from Visual SourceSafe to Surround SCM Integration Provider. If you’re converting from another source code management tool, the steps will be similar.

Before getting started, make sure the following are installed:

• Visual SourceSafe
• Visual Studio (2005 or later)
•  Surround SCM Client
•  Surround SCM’s Visual Studio 2005, 2008, and 2010 plug-in

If you do not have the Surround SCM Client and/or plug-in installed, you can download the client installer here: http://downloads.seapine.com/pub/upgrades/sscmwininstallclient.exe

You’ll also need to make sure a mainline branch has been created in Surround SCM.

IMPORTANT: Make sure that any changes you have made to the files in Visual SourceSafe are checked in before performing the following steps and you have the latest version or your project and files on your machine.

Unbinding the solution and projects

1. Open the existing solution in Visual Studio. You should see lock icons next to each item, indicating the solution is bound to Visual SourceSafe and not currently checked out.

Figure 1: Solution bound to Visual SourceSafe

2. In Visual Studio, select File > Source Control > Change Source Control.

3. Select the solution in the list and click  “Unbind”.

Figure 2: Unbind the solution

4. Click “Unbind” to confirm that you want to unbind the solution.

Figure 3: Unbind confirmation message

5. Select the project in the Change Source Control window and click “Unbind”.

6. Click “Unbind” to confirm that you want to unbind the project.

7. Repeat steps 5 and 6 until all projects in the solution have been unbound.

8. After all projects have been unbound, click “OK” in the Change Source Control window.

Binding to Surround SCM

1. In Visual Studio, select Tools > Options.

2. In the Options window, click the Source Control tab on the left.

3. Change the current source control plug-in from Visual SourceSafe to Surround SCM Integration Provider and click “OK”.

Figure 4: Change provider

4. In Visual Studio, select File > Surround SCM > Bind/Unbind Settings…

5. Select the solution in the list window and click “Connect”. If you’re prompted to log in to Surround SCM, enter your username and password, then click “Connect”.

6. Select the solution in the list window again and click “Bind”. The Surround SCM Repository Browser: Open for Solution window opens.

7. Select the branch and the repository that you want to add the solution to, then click “Create Repository”.

Figure 5: Create solution repository

8. Enter a repository name and working directory for the new repository. The working directory should be set to the directory where the solution file resides. For example:

Figure 6: Enter repository name and working directory

9. Click “OK” in the Create Repository dialog.

10. Click “OK” in the Repository Browser window.

11. Select the project in the Surround SCM Connection Settings window and click “Bind”.

12. Click “OK” in the Repository Browser window.

13. Select the same branch as before and the repository that contains the solution file, then click “Create Repository”.

Figure 7: Create project repository

14. Enter the name for the new repository and the working directory path, which should be set to the directory where the project resides, and click “OK”.

 Tip: By default, the Surround SCM plug-in selects the working directory as a sub-directory of the parent working directory. If your project isn’t in the default path, select and then deselect “Inherit working directory from parent”, which will allow you to edit the working directory path.

Figure 8: Create repository

15. Once the solution and all the projects have been bound, click “OK” to save your changes.

16. Right-click the solution file in the Solution Explorer window and select “Add to Surround SCM”.

17. Verify the binding information and click “Yes” to bind to the specified location.

Figure 9: Bind confirmation

Your solution has now been bound and added to Surround SCM.

http://downloads.seapine.com/pub/beta/scm/xcode/SurroundSCM_xCode4.2_beta.zip

This video shows you how the integration works and how to do a few basic things, including viewing file history, viewing differences between document versions, and merging different versions of a document.