Your relation to your source control system

Do you feel that your source control system is working against you? Well, it might not be perfect, but maybe you’re just rubbing it the wrong way. I find that if you are a bit unstructured in your approach towards it, you can easily get into some unnecessary problems. And a little structure is all that it takes in order to make your source control system a lot more frictionless.

This is how I work with my source control system:

First, what do I check in? Logical chunks that work.

Then, how do I check it in?:

1. You start with no local changes (that’s the best way to start the day)
2. Get the latest source from the source control system.
3. At this point you want to be certain that not anyone else have broken anything, do one of the two:
• Have a build server that notifies when there is a check in, if the last check in was ok, then you’re good to go (this is by far the preferred way)
• Run the tests just after getting the latest source
4. Do what you came here for: code. Whenever you have a logical “chuck” of code, proceed to the next step.
5. You want to be certain that what you are about to check in is working: Run the unit tests one last time to make sure your code is working.
6. You have to merge your changes with anything else that might have changed: Get latest from the source control system.
7. Run the unit tests: At this point, you want to be certain that the combination of your code and the code from the repository is not failing anything. (Here it is a great advantage to have a build server that tells you that the source you are getting from the source control is working, so any failing tests you get now are guaranteed your fault)
8. Fix whatever is broken
9. check in (when all tests are green)
10. Repeat

Also note:

• On a general note, do your best not to check in failing code (failing tests, or even not compiling code). Failing code impeeds all the other team members. Don’t you get really annoyed when someone else on your team are messing up the source, and making lots of extra unnecceary work for you? I do not want to be that person.
• Do not, I repeat: do not, check in anything before getting the latest source. You want to make sure that all the latest source (not just yours) are working together.
• Do not wait too long to check in (to check in at least once a day is a good rule of thumb). The longer you wait, the more merging you will probably have to do.
• It is also a big advantage to have a build server that notifies if someone checks in failing code (so you do not have to be uncertain if it was you or someone else that broke the code when you get the latest source)

I am very interested in hearing your experiences with how to work with source control systems, feel free to post comments.

- Tore Vestues