Frequent check ins frequent integration previous: The best checkin comment ever next: Code Generation and the Open Close Principal A few days ago there was a thread in the ALT.Net mailing list about the frequency of check ins. Here is my opinion in this matter: Comments 03/28/2008 07:29 PM by Jeremy Gray I'm a big fan of frequent check-ins as a result of fine work decomposition, however I do wonder about changeset 17205: Depending on your interpretation of "do not use", that shouldn't have been checked in, as it broke the project. Not so much in a "broke the build" sense, rather in a "broke any other dev that checks out as of 17205 sense." 03/28/2008 07:39 PM by Ayende Rahien No, the last checking refers to users who might want to use this. At the moment, it works, pass all the tests, but it not verified enough for me to be comfortable to release to users. 03/28/2008 07:45 PM by Josh Maybe I just missed a post with the explanation, but why are you spending so much time on the svnbridge project? 03/28/2008 07:48 PM by Ayende Rahien Josh, I am getting paid to do so. 03/28/2008 08:08 PM by Jeremy Gray @Ayende - I figured that'd be the case. :) 03/29/2008 12:58 AM by Pierre-Marc From 5 am to 7 pm ???? 03/29/2008 01:18 AM by Ayende Rahien No, Thu 08 PM - 5 AM Fri 1 PM - 9 PM 03/29/2008 01:25 AM by Pierre-Marc hihi, anyways from my point of view, I try to split my expected work of the day in 4 to 6 tasks and check-in after each one. 03/29/2008 01:30 AM by Ayende Rahien I tend to commit whenever I have a stable system 03/29/2008 02:39 AM by pb I check in as frequently as him. For me, as long as it is passing all tests and I have completed a unit of work, I check in. I like being able to just blast everything with an undo checkout on the whole project if something doesn't work out and too many tests get horked up. 03/29/2008 09:47 AM by Frans Bouma I also favor frequent check-ins. The biggest feature of a sourcecontrol system is that you have a history: you can rollback to a known good state. So even if you have to make 3 changes to the same code file, if these 3 changes are actually 3 different bugfixes for example: check in after each change. Another thing which might be considered is checking in after a day of work, even if the code doesn't build. If it doesn't build: check into your own branch, add #error and #warnings where you were at and what to change the next time you're working on that code. Of course, when you add #error and #warning lines, be sure to check into a different branch, but that's what they're for anyway :). The advantage of this is that if your own box crashes, you stil have your work. When you're done you merge with the trunk (that's why there's a merge feature ;)) 03/29/2008 09:53 AM by Ayende Rahien I agree, except the checking in to a private branch. That certainly work, but I tend to prefer generating a patch file and storing it on the server as opposed to a branch. 03/29/2008 04:31 PM by pb We actually have ours setup as a branch called Production instead of Main. You don't check in broken code to that, ever because hotfixes are done right in that branch very quickly without having to check with anyone. We all work off a network drive that is snapshotted hourly and nightly so there isn't much concern about losing code if you don't check in for a while but you can shelve if you want. And we don't leave if something isn't working either.. :) Working state to working state makes life easier - and sleep easier too and isn't too hard if you take a little piece at a time. 03/29/2008 07:04 PM by Igor Brejc There's another interesting discussion I happened to be involved in yesterday about the future of CI which also touches on the frequency of commits and the "trunk development" vs. "branch per task development" paradigms: http://codicesoftware.blogspot.com/2008/03/continuous-integration-future.html 04/06/2008 08:53 PM by Fervent Coder I can say that I check in at least that frequently. Being on team development, when I am ready to check in I integrate locally first, build, run the tests and make sure they pass. Then I check in. Being on TFS, I also don't keep the solution or project files checked out longer than to add a reference or a new file (classes mostly). Once added, both get checked in and then the new class gets checked back out for me to add the functionality to. This behavior doesn't break the build and gives the added bonus of not causing others to have to merge more than necessary. Comments have been closed on this topic.