Source Control Pet Peeves

Wednesday, September 1, 2004
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.

Andy Wednesday, September 1, 2004
I take it you are using source safe then? Try Vault from what I hear it beats the pants off source safe and doesn't eat projects like source safe does. I originally got the link to it from Joel Spolsky I believe his company uses this for version control etc of their Fog Buzz product. I think it even has built in integration with FogBuzz so you can do bug tracking along with the version control.
Jeremy Brayton Wednesday, September 1, 2004
Vault is excellent, especially on a personal level. It's free for personal use and works on a MSDE database so you can keep everything all on say one XP machine.
<br>In a team environment you'd probably want the full version or something like the Team stuff MS is coming up with. VSS hasn't changed in years and I'd be more inclined to go with a CVS approach than try my hand with that beast. If you are doing personal programming though Vault would be the best solution.
<br>The only part about Vault I don't like is the fact that everything is stored in the database. I can't retrieve files easily or backup directory structures. If the database corrupted, all of my work would be gone. I would rather have the database store the information about the files and have a backend filesystem solution so that I can either backup the directories or the database without so much dependency on the database. I like a more CVS approach personally.
<br>When working on a project, it's easier to keep the same names. If you need an earlier version, you can always get it from the repository. Changing the name from Blah to Blah3.cs isn't usually easy. What if you had uses clauses? You would have to change those to match the new name. Resource includes? Change the link. It's a lot of work depending on which file you're changing so it just makes the most sense to keep the filenames relative and let the content of the files decide which version of the product it is.
Comments are closed.

My Pluralsight Courses

K.Scott Allen OdeToCode by K. Scott Allen
What JavaScript Developers Should Know About ECMAScript 2015
The Podcast!