Source Control Pet Peeves

Here are a couple of my pet peeves in source control.

Let’s say the sales and marketing department has decided the company is about to build version 3.0 of an amazing product: FooBar. Sometime thereafter, someone checks in a file named FooBar3.cs into source control.

I see two problems here. First, source control software, also known as version control software, will manage versions all by itself. Instead of putting version numbers in the file name, leave version numbers to the tool. When it comes time to associate a file version with a specific product release, I use the tagging / labeling functionality of the tool, and avoid potentially confusing conversations like:

Is FooBar3.cs checked in to build FooBar 4.0?

Does FooBar 5.0 still have FooBar3.cs?

This reminds me of an RFC on machine naming conventions (which I can’t find now). It suggests not giving the computer a name like UP or DOWN, because technical support will get calls like:

Is DOWN up?

Is UP down?

The second problem is letting a product name into the source code. Product names belong to marketing and sales. Product names are subject to change with the phases of the moon. Today the product is “FooBar 3.0”, tomorrow the product is renamed “Fabio 2005”.

Code names - really cool code names - like “Death Star” and “Predator”, belong to engineering. No one can make you change a code name. Well, unless you are Apple. In 1993 somebody at Apple decided to use “Carl Sagan” as a code name. Sagan’s attorney sent a letter to Apple asking them to stop. Someone at Apple then decided to change the codename to BHA – short for ‘butt-head astronomer’. Sagan then filed suit for emotional distress.

My advice then is this: don’t use version numbers, product names, company names, or the names of humor-impaired scientists when naming your project artifacts. Still, you might want to check with your lawyer first.