How NOT to Implement Source Control
Damian recently spoke out on versioning code, and it reminded me of a nightmare I'm involved in with versioning documentation. Yes, it's true, documents (you know, things like written specs, test plans, etc.) have versions, too. Well, believe it or not, I have a client company that is using source control software (CVS in this case) for their code, but not for their documentation. But it's not that it never occurred to them that they would have multiple versions of the documentation. Instead, some genius came up with the idea of putting a version number in the file name. And if that's not bad enough, they also put the “last updated” date in the filename. And the date may change but the version number doesn't. So the documents are named things like “blah blah blah spec v3 20030930.doc”. And then (hopefully) older versions are moved into a sub folder called Archive.
Do NOT do this! It adds confusion if the older versions don't get archived. It makes it harder to point someone to the right document. And if you have someone working off-site (like me) it's a royal pain to get them the current version. Instead of overwriting my previous version with the new one, I now have multiple versions of the document when all I care about is the current one, and now I have to waste my time wading through the file list to find the right one, and delete the older ones. Why these people didn't check their documents into the source control like they do the code, I have no idea. But whatever you do, don't follow this Worst Practice.