Friday, November 23, 2007

“Source Code Repository” Defined/Explained

When developing software, the source code is your most valuable asset. A Source Code Repository is a special database where the source code is stored.

Source Code Repositories—also called version control software—usually have the following types of features:

  • The ability to check out and check in code. When you check code out, it means that you’re locking that piece of code, so that other developers know not to work on it (or can’t work on it) until you’re done. When you’re finished with it, you check it back in. (Sometimes repositories are set to allow multiple people to check a file out at the same time; in this case, the changes have to be merged together, as explained in the bullet below.)
  • The ability to compare different versions of a file, and merge versions together. Comparing allows you to see what has changed, between the code you have on your computer and the code that’s checked into the repository. Merging allows you to take changes from multiple versions of a file, and combine them all together into one final version of the file.
  • The ability to label a particular version of the code. (Different repository products have different naming conventions for this; they don’t all call it a “label”.) Normally, the software you’re developing will go through multiple iterations; you’ll have version 1.0 of the software, and then 1.1, or maybe 2.0, etc. With each version of the software the code base changes. However, if you label your code, from time to time, you can always go back and get the code as it was at any particular point in time. e.g. “get me the code as it was when I labelled it ‘1.0’.”
There are a number of vendors who provide source code repositories. Some of the ones you’ll see most commonly are CVS, Subversion (SVN), and, in the Microsoft world, Visual SourceSafe.

Deployment: November 2007 (almost)

This was going to be an unusual deployment, because it was scheduled for a Wednesday night, instead of a Saturday night. This worried me, because I was worried about having to work on Thursday, and I was coming down with a cold.

It was also going to be a long deployment; there is another system we depend on, that had to deploy along with us, but their deployments are much longer than ours. So we would have had to shut down our system, and then wait for a couple of hours, until they were done, and then continued on with ours.

As luck would have it, though, their deployment was deferred. Their source code repository crashed, and they spent days trying to recover from it. So we’re rescheduling for this coming week. And the good news keeps getting better: we’re hoping to deploy the other application on Monday night, and my application on Wednesday night—so we won’t have such a long deployment.