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

~Dave

That sounds like a post for the daily WTF!

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.

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

I first read that:

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

Which is probably true...

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.

@Will,

That line of thinking is just plain WRONG

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.

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.

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.

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.

Alk.