Favor small and frequent checkin over big ones.

This is a rule that I try to adopt since long time in the past, and few days ago Jeff Atwood enforces this concept in his blog. I completely agree with him, code should be checked in often, especially when you have continuous integration server. Checking in often reduce the risk of conflicts, makes tests run often (you should have setup your continuous server to run all tests for each checkin) and makes integration simplier. Benefit of frequent checkins are

  • Other developers are immediately aware of yours modifications, you can have immediate feedbacks
  • As I said tests are run often with code of other developers (think to the scenario where you finally merge your changes and with pain you verify that a lot of tests are now failing)
  • if some code path is gone wrong, you can simply revert local changes and begin again from a good starting point.

I usually follow the pattern of “implement something new, run all tests, update local files again to check for conflicts, resolve any conflict, then commit with a comment telling the reason of the commit”. When I correct bugs, I correct a single bug, then run the tests, update, resolve conflicts and commit with a comment that tells the number of the bug that was corrected.

But sometimes programmers are going into big changes of the code, they begin to change a lot of files, and tends not to checkin until the work is finished, this is wrong. One possible solution is creating a branch, you can checkin often without the risk to break the build, you can checkin incomplete code (the only condition is that it compiles), you can watch out the change on the corresponding files on the trunk, so you can merge often from the trunk to your branch, and finally when you are done with the change you can merge last stuff and move into the trunk the new code. The greatest advantage of this approach is that the other programmers are continuously aware of your work. Suppose programmer A find a bug in class Foo, he can correct the bug on the trunk and immediately make the same correction on all active branches.

Another approach can be taken when you use IoC in your application. Suppose that I need to radically refactor component Foo that implements the interface IFoo. I simply begin to create another component called Foo2 or FooBetter or whathever you like, I develop it, test it, and when I think that it is finished I simply change configuration file to use the new component. When everyone says that the new Foo is ok, then I can delete the old Foo. The good thing is that I can run all test suites regarding the old Foo class against the new one, until all the tests passes.

Both these approaches are better than keeping local changes for too long and doing a final big chekin. Remember the rule, favor small and frequent checkins over big and infrequent ones.

alk.

Tags:

 

Published by

Ricci Gian Maria

.Net programmer, User group and community enthusiast, programmer - aspiring architect - and guitar player :). Visual Studio ALM MVP

3 thoughts on “Favor small and frequent checkin over big ones.”

  1. I agree. This concept works nicely when combined with Agile Development like Scrum/TDD. Frequent check-ins with proper version/build labels allow for mananiging a solution deliverable a lot quicker. The bigger the project/team, the more frequent checkins the less pain you will have in the long run.

  2. Prior to Scrum, we were following a pretty typical Waterfall model and one of the challenges we were facing was creating different kinds of project branches in VSS. You can branch out the code but it is still just different folders. We would do the development in each of these folders (project branches) but the merging of the releases became almost impossible as we got bigger. The biggest overhead we were facing was in the merges and making sure that changes that are supposed to have been brought up to the same baseline were done accurately. We had to allocate a week or so with one or two developers making sure that after a given release was done, that all the changes were propagated. If we had a ticket that had to be fixed and now there were four project branches that were active at any given point in time, you would have to manually apply those changes in those four places because there wasn’t an easy way to propagate them back to the parent and merge them all together. We now are able to do private check ins that Accurev has that is just incredible for us, at least in my opinion, because that lets the developer work locally in a way somewhat disconnected but at the same time connected because the server is always keeping track of all the changes. Before I could bring the code locally to my lap top, I could work for 15 days, and wouldn’t know a thing about what I changed. Only at a point when I was ready to check in, I would just check in without knowing that I would be in conflict with something else or not. This post was interesting for me because those things were really a nightmare for us to manage. We had situations where one developer would overwrite another developer because they were working off an old baseline and those types of things. We survived it, but the project teams were not as big as they are now, so it was somewhat manageable because the number of people making the changes was somewhat limited. And then the way we had structured our code was that they would have 2 separate branches where 2 separate teams would work, so we had physical separation and every time we were doing a feature development in one and it had to be quickly made available to the other it was almost an impossible task. Because your baselines would be different, the merges would not be so easy and all kinds of issues would arise. Incremental merging and not putting off until the end of an iteration has been key.

  3. Yes, more time you spent with local checkout, more merge work you will have to do when you commit, and if the time is really high…..merge is a nightmare.

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.