Ayende @ Rahien

Refunds available at head office

Source control practices to be abolished: The Large Checkin

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.

Comments

Dave Newman
04/24/2008 03:11 AM by
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? ; )

~Dave

Fervent Coder
04/24/2008 03:41 AM by
Fervent Coder

That sounds like a post for the daily WTF!

Jason Stangroome
04/24/2008 07:11 AM by
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
04/24/2008 07:17 AM by
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
04/24/2008 07:43 AM by
Will Shaver

I first read that:

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

Which is probably true...

Vijay Santhanam
04/24/2008 09:04 AM by
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?

DannyT
04/24/2008 11:29 AM by
DannyT

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
04/24/2008 12:27 PM by
Derik Whittaker

@Will,

That line of thinking is just plain WRONG

Chris Ortman
04/24/2008 01:40 PM by
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
04/24/2008 02:43 PM by
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
04/24/2008 03:03 PM by
Ayende Rahien

Adam,

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

Jeff Tucker
04/24/2008 09:16 PM by
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
04/26/2008 06:48 AM by
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.

Alk.

Comments have been closed on this topic.