Ayende @ Rahien

My name is Oren Eini
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by phone or email:


+972 52-548-6969

, @ Q c

Posts: 6,026 | Comments: 44,842

filter by tags archive


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

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.


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

Ayende Rahien


I am getting paid to do so.

Jeremy Gray

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


From 5 am to 7 pm ????

Ayende Rahien


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.

Ayende Rahien

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.

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

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.


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.

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:


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.

Comment preview

Comments have been closed on this topic.


No future posts left, oh my!


  1. Technical observations from my wife (3):
    13 Nov 2015 - Production issues
  2. Production postmortem (13):
    13 Nov 2015 - The case of the “it is slow on that machine (only)”
  3. Speaking (5):
    09 Nov 2015 - Community talk in Kiev, Ukraine–What does it take to be a good developer
  4. Find the bug (5):
    11 Sep 2015 - The concurrent memory buster
  5. Buffer allocation strategies (3):
    09 Sep 2015 - Bad usage patterns
View all series


Main feed Feed Stats
Comments feed   Comments Feed Stats