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."

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.

Maybe I just missed a post with the explanation, but why are you spending so much time on the svnbridge project?

Josh,

I am getting paid to do so.

@Ayende - I figured that'd be the case. :)

From 5 am to 7 pm ????

No,

Thu 08 PM - 5 AM

Fri 1 PM - 9 PM

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.

I tend to commit whenever I have a stable system

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.

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 ;))

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.

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.

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

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.