Source Code Control

One - Revision  Maintenance

Let's say you release version 2.0 of your software.  It is a big success, but it has some bugs.  So, you release 2.0.1 and 2.0.2 to fix the bugs, then you add some new functionality and call it 2.1.  There are still some bugs, so you release 2.1.1, and win the product of the year award.

You get a  call from your biggest customer, who is still running 2.0.2.  They are having trouble with a bug you fixed in 2.1.1, but they can't run 2.1 or anything after it because of their old operating system, which is scheduled to be reviewed by the OS committee in 2033.  They are asking for a 2.0.3 release.

Source Code Control systems have all the tools to deal with this problem.  You can make branches off old version of code (which you have carefully stored), and you can apply changes to more than one branch.  You can also compare different version to see what changed.

Two - Oops, Restore

In this example, you are assigned to implement the new web interface to your popular server.  Each day the code gets a little better, as you add more functionality.  But one day, all hell breaks lose.  It is as if something you did is corrupting the disk drives at some random time after a request.  But you have no idea what the problem is, and you don't know where to look.  Do you delete all the code and check out a fresh version?  Do you spend weeks debugging?

Or... You are working furiously to meet the deadline.   Your piece of the system is almost done; you just have a couple more bugs to fix.  Suddenly, your editor locks up.  Nothing will clear it, so you reboot. Your system will not come up.  You put in a midnite call to IT and within 18 hours you are the proud owner of a brand new computer.  Your old disk was toast.  Your work is gone.

 Did you ever play adventure games?  After a week of getting stronger, you work your way into the dragon's cave, find the secret passage and you almost get the gold, when the dragon finds you.  "With one puff of fire, YOU ARE DEAD!"  Do you start all over?  No, you just push the restore button and go back to where you ten minutes ago.  Maybe you should back up a day to before you entered the cave and get more weapons.

Writing code is just like playing a dangerous adventure game.  You save your state at a few nice stable places where you feel safe.  Then, if you get in trouble, you just go back there.  Or maybe you just compare your state with the last safe one, and see what has changed.  It takes the death out of programming.

The Two Systems Are Different

 The first system is all about carefully tagged branches with formal names.  These need to be kept forever.  The second system is very informal, and every single save, except the last one, is incomplete junk.  Maybe you save them forever and maybe you don't, but don't let them clutter up your formal releases, or you will never find anything in all those checked in versions.

 I recommend having  two different SCC systems.  One is under tight control and might have some committee to approve all changes to it.  It should be backed up into some hollow mountain periodically.  Advanced tagging and branching features are a good investment.  The second system  needs to be informal, so that every programmer can check things in at any second they feel their code is ready.   Advanced features are rarely used, so a cheap system may save you money. 

Continuous Integration

Integration is one of the great killers of software projects.  The code gets written on schedule, but it takes a month to get all the parts to work together.   Or, the schedule calls for six internal releases to Test before the final release.  But it takes seven or eight tries to get each internal release to build.

Some wise teams are doing their builds every day.  That way, they fix the problems as they go instead of saving them all for integration.  

This requires something between my first and second model of source code control.  Daily releases have to be coordinated, so nobody makes calls to code that is not written yet.  Your daily release is not just another random save, and the programmer is not the only one who might have to revert to a previous version.

 If anyone has any magic solutions to this problem, I would like to hear about it.