Gosh, I really learned a lot from that chapter. I'm not being sarcastic, that was honestly very informative to me.

Ha! Too late, Mike, I read it...

Here's one statement in your chapter:

Forget attempting to access SourceSafe remotely. Searching thousands of files over a pokey internet connection is murder. Dont even try it.

Hypnos Entertainment developed Jack Nicklaus Golf 6 entirely with telecommuting programmers using SourceSafe. You're right, it was sometimes slow when many files changed, probably because SourceSafe made separate file transfers for every little file. But in fact it was not awful, and wasn't really a problem even during the final weeks of shipping. We always wanted it to be faster, of course, but it certainly wasn't killing us. Right at the end of the Jack6 project, a product called SourceSafe Offsite was starting to be advertised. I never got a chance to try it, but it may address some of the Internet inefficiencies.

EA Seattle used SourceSafe for some things, but for offsite work I just used RemoteDesktop, which completely circumvents the issues of sending source files over the Internet anyway.

In using SourceSafe for over 7 years, I had personally never seen such corrupted database problems that the Analyze utility couldn't resolve. But recently...l

I personally saw a corrupted SS database that wouldn't let you ever check in or out of a corrupted subfolder. A week later, a second subfolder becomes perpetually checked out and unusable. The Analyze utility was unable to resolve the problems.

This happened in a shop that (in a decision that I was not part of) used SoureSafe to hold huge art binaries. Arguably, these files were not even actually "source", they were intermediate files. It was akin to having programmers do source-control on obj fiiles but not on the CPP files, but it's common for game shops to struggle with source controlling art. Often artists don't even know what files truly constitute their source, because Max or Maya will use internal references to who knows what texture and reference files. But I digress...

My point here was just to back up Mike, in that SourceSafe definitely chokes on large data.

Another major issue is that SourceSafe does not support making a group of operations atomically. Perforce is awesome at letting you define a whole group of deletions, edits, renames, whatever, to many files all at once , and submitting it as a changelist. SourceSafe treats changes just one file at a time, so you must take special care especially when deleting or renaming source files.

A practice I am fond of when deleting a file from a SourceSafe database is to defer actual deletion of file for a few weeks. SourceSafe will not remove deleted files from client machines (Perforce will), but it will still update a file if you check in a change, so, instead of deleting the file, check in a version of that file that contains a line:

#pragma error This file has been deprecated

And then leave this in the database for a few weeks, until you're reasonably certain that all the client machines no longer have the old version. Do this for files that you just moved to a new folder location too. That way, if this is a header file, for example, you'll know that the compilers on other users' machines will not be accidentally #include'ing the files from files in the stale location.

--dclark

The importance of this chapter is truly awesome, and your admonitions are dead on. I don't want to make your chaper any longer, but here's some things that I don't believe I noticed, but I personally find indispensible now:

--Run the unit tests as part of the build
--Build the installation EXE, debug and release
--Automatically bump the version's build number

By unit tests I mean that the game isn't the only exe you should be building. On a recent project I had several lightweight console app exes's built right along with the main product. These console apps were unit tests that performed simple sanity checks on core code like math classes, serialization, memory support, etc. Often, these tests used special input files (some that were purposely broken files, to test error handling!!), and these test files were part of the project and were source controlled.

The build would compile and execute all these little unit tests prior to building the main product. I generally wrote these apps such there main would return an integer (the number of errors) to DOS, so that my batch files could just check ERRORLEVEL before proceeding. There's probably cooler ways to do that now.

Building the installer/uninstaller was an immense improvement over having the testers perform manual installations. They could easily regress to earlier versions and also we simply avoided a second, post-installer test cycle. Right from the beginning, we were able to keep dll and registry issues completely synchronized, testable, and under control.

Incrementing the version number automatically isn't too hard, unless you're using a Windows VERSION resource, and using DevStudio's Resource Editor to author it. I'm sure some scripting guru knows a better method to do what I'm about to describe, but in one shop, what we did was write a simple console app to increment the "build number" part of the version number. To change, say,

from: #define Version 4.2.1.9
to: #define Version 4.2.1.10

Our little utility was crude and only understood files that had just this one line of code in it. We named this one-line file "Version.h" and coerced the project resource.h files to #include and use it in the exe's version resource. With a Windows app that has a version resource built in, you can right-click the EXE, click "properties" and see this version number. (You don't have to execute the program and do help/about in other words) The testers loved this.

Again, the particular tactics are a kludge and probably offensive to some snappy scripter out there, but the strategy is good: the last step of your build process (if everything goes successful with constructing the exe and installers), is to check our Version.H, run your little build-number-increment utility, and check in the updated Version.H.

You can always manually check out and update the other fields of the version info according to your shop's policies, but leave the build number field for your automated build.

Consoles of course won't have a version resource per se, but it is still good to have internal version string with a build number.

Maybe this is all built into some durn third-party commercial magic build package now too.

--dclark