Procedures before checking in to source control?

Question

I am starting to get a reputation at work as the "guy who breaks the builds".

The problem is not that I am writing dodgy code, but when it comes to checking my fixes back into source control, it all goes wrong.

I am regularly doing stupid things like :

• forgetting to add new files
• accidentally checking in code for a half fixed bug along with another bug fix
• forgetting to save the files in VS before checking them in

I need to develop some habits / tools to stop this.

What do you regularly do to ensure the code you check in is correct and is what needs to go in?

Edit

I forgot to mention that things can get pretty chaotic in this place. I quite often have two or three things that Im working on in the same code base at any one time. When I check in I will only really want to check in one of those things.

Answer 1

I usually always do a Get Latest before, then build. If build is good then I check in my code.

Answer 2

A few suggestions:

• try work on one issue at a time. It's easy to make unrelated changes to the codebase that then end up being committed as one big chunk with a poor log message. Git is excels here since you can so easily move switch branches, and stash and cherry pick changes.
• run the status command before a commit to see which files you've touched and if you've created new files that need to be added to version control.
• run the diff command to see what you've actually changed. Often times you find that you've left in some debug logging that should be taken out or made some unnecessary change that is just cluttering up the diff. Try to make your diffs as small and clean as possible.
• make sure your working copy builds with your changes in it
• update before checking in and make sure that your working copy builds with other peoples changes in it
• run what ever smoke test suite you might have to make sure that your changes work correctly
• make small and frequent commits. It's a lot easier to figure out what has broken the build when the breaking commit is small.

Other things that the team can do is setup a continuous integration server like David M suggested so that the broken build is discovered as soon as possibly and automatically.

Answer 3

In the past I have used branching in Clear Case to help with this issue. The process I used is below. I've never used SorceDepot so I do not know how this can be adapted to work with it.

1. Create a branch for the bug fix
2. Code all changes on the branch
3. Code Review
4. Merge to stable branch in a different view (the different view is important)
5. BEFORE checking in: compile, test, and run
6. Check in code to stable branch

By creating the branch and then merging the changes to a different view (I use Merge Manager to do the merge) any files that were not included or checked in immediately cause issues. This way everything gets tested as it will be when checked in on the stable branch.

Answer 4

The best thing to avoid your problems, is to use hooks, that are provided in most SCMs (they are for sure in SVN and Mercurial, and I believe they must be in other advanced SCMs). Attach unit tests to the hook and make it run every time someone checks code in - exactly before it is checked in. This way you will achieve two things:

• code in SCM repo will always pass the tests,
• you won't make most simple mistakes, because they should be easily detectable, if you have decent test suite.

Answer 5

First, use multiple working copies (a.k.a sandboxes) - one per issue. So, if you've been working on some complex feature for a while, and you need to deal with a quick bug fix on the same project, check out a new clean working copy and do the bug fix there. With independent working copies for each issue there is no confusion about which changes to commit from the working copy to the reposistory.

Second, before committing changes, always perform the following three steps:

1. Buld the software.
2. Run a smoke test (does it start and run without crashing).
3. Inspect the changes you're checking in by diffing your changes against the baseline.

These should be repeated after any merge operations (e.g. after an SVN update).

Answer 6

Here is what I have been doing. I have used ClearCase and CVS in the past for source control, and most recently I have been using Subversion and Visual Studio 2008 as my IDE.

1. Make my code changes and build on the local machine.

2. Make sure they do, in fact, fix the bug in question.

3. Run an SVN update on the local machine and repeat steps 1 and 2.

4. Run through the automated unit tests to verify that they pass.

5. If an automated smoke test is available, which automatically tests a lot of the system's capabilities, run it. Verify that the results are correct.

6. Then go to the build machine and run the build script.

If the project's configuration has changed, this could definitely break a build. Perform an SVN update on the build machine, whether the build script does that or not. Open the build machine's copy of the IDE, and do a complete rebuild. This will show you whether the build box has any problems that you have taken care of on your machine but not on the build box.

The suggestions to keep separate branches for each issue are also very good, if you can keep track of all of the issues you are working on.

Answer 7

I like having Tortoise plugins for Windows Explorer. The file icons are all badged with committed, modified or not added icons making it very easy to see what status the files are in. I also enable the meta data for Modified so I can sort changed files in the list (Details) view, where they bubble to the top so I can see them.

I bet there is a Tortoise* plugin for your SCM, I saw one for Mercurial and SVN (and CVS, ugh). I really wish Mac OS X's Finder would accept plugins like Tortoise, its so much easier than having to pop open a dedicated app most of the time.

Answer 8

At my workplace, the safety net for this is peer review. That is, get someone else to build, run, and reproduce your solution on their machine, on their view.

I cannot recommend this enough. It has caught so many omissions, would-be problems, and other accidental pieces of junk to make it a valuable part of the process. Not to mention that the mere knowledge that you have to place your work in front of someone else before having it go on to the main branch means that you raise your own quality standards.

Answer 9

Get someone else to go through "every" change "before" you check in the code.