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

Source control practices to be abolished: The Large Checkin

time to read 1 min | 95 words

I have just had to make a modification to SvnBridge because someone decided to checkin a change set that included 1,695 changes..

Even ignoring the issue of "your checkin broke my source control" mentality that I have now, this is bad from other perspective.

How do you review such a change? How do you even know what is going on there? In changes of this size, you aren't making a single change, you are making a lot of changes. Now you can't mix & match them either.

Prefer small checkins, they are easier to deal with.


Dave Newman

I've moved over to Git now, and am really digging the workflow.

I've also noticed now that my commits have become more concise and focused around particular features. Though I can't point my finger on exactly why.....

ps. GitBridge? ; )


Fervent Coder

That sounds like a post for the daily WTF!

Jason Stangroome

I totally agree that big check-ins are a bad idea but is the file count an accurate measure of a big check-in? Perhaps, purely for example, I did a global find and replace on the namespace prefix thoughout a solution and checked in... this would probably touch every source file, project file, and build script. However, in each file it would only be a small change to a single line.

Benny Thomas

It wasn't me, but sounds like a huge refactoring. But I'll recommend the next time "someone" should checkin a bit earlier.

Will Shaver

I first read that:

"Prefer small CHICKENS, they are easier to deal with."

Which is probably true...

Vijay Santhanam

That's a big check-in. The wide name changes is one explanation, or too lazy to check-in neatly divided features.

But another plausible reason that Git solves is the large experiments that the developer is unsure will work in the long term - why ever check that in?!

When the experiment eventually works out - what are they to do? Clearly, they just check it in!

The same thing happened to me today, but the PM saw it coming.

Isn't this an inherent limitation of non-GIT/Distributed source control?


Forgive me if i'm missing the obvious, but isn't this what branches are for? The 'big chicken' (thats how i read it too :P) developer should have had his own branch to make his incremental changes whilst still checking in and not disrupting the main branch.

Unless of course it's as per Jason's suggestion and was a find/replace, but even then source control is not a replacement for team communications.

Derik Whittaker


That line of thinking is just plain WRONG

Chris Ortman

It's been a while, but isn't a merge in svn done as one big commit?

IMO the reason for smaller checkins in git are because it is so much faster. The time it takes to do git add . git ci -m "" is trivial, so frequent commits are easy.

Adam Tybor

Even with small local commits with git or to a branch, how can a maintainer easily review the final "BIG" commit to the working trunk?

I would use git and prefer to review 100 tiny checkins with comments over a single commit of 1600+ changes. So I think git is still the answer. Either way a major refactoring like that is going to be tough to review regardless of the tools or process.

Ayende Rahien


Yes, you hit the major point about why I dislike distributed SCM

Jeff Tucker

What if you do some sort of global change to the application though that's really smally? For example, maybe I change the root namespace for some reason. It hits every single file in the application but only changes one or two lines per file and it's a predictable change. I think that as long as that were the only change in that check in it would be fine. Still would be annoying, but I don't have a problem with it. On the other hand, if someone checks in 1200 files and there are 50 new features associated with that check in, someone needs to check code in more often.

Gian Maria Ricci

surely a check in with 1695 changes is too big. I think that another unit of measure to find "big" change set could be the time that pass between the instant you modify a file, and the time you chek in the repository. More is the time you take the file with changes in your local copy, higher the chance of confilcts. I always suggest people to have a branch in situation where they needs more time to reach a stable point. In this way you still deal with rapid checkin and you do not affect the trunk.

I prefer small and fast checkin, expecially when you link the check in with an issue in the bug tracker, just correct the bug, and fire a check in.


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