Home > Distributed Version Control > Why committing early is anti-social

Why committing early is anti-social

This article expresses concern that distributed version control encourages the anti-social behavior of developing code without community input. However, the proposed remedy, committing early and often to a central repository, is itself anti-social, albeit in the opposite direction.

Think about that situation for a moment. Everyone who has worked on a relatively large code base has experience with this. What happens when someone commits to a central repository? Everyone who wants any changes is forced to take all the changes, whether they want them or not, whether they work with your own local changes or not. For me, these problems always seem to occur when I’m rushing to check in before going home and I do a quick update to get in sync.

Yes, it’s possible to back those changes out, but it isn’t trivial to separate them, and one way or another, you have to deal with the changes, and you have to do it on the submitter’s timetable. It’s the equivalent of shouting in a movie theater because you want to hear what your friend sitting next to you thinks. It’s disruptive, and it’s only tolerated because it’s better than having everyone develop “in a cave.”

Notice it’s the committing of the code that’s disruptive, not sharing the code. With centralized version control, there isn’t much difference, and we’ve slowly come to accept that as the way it is. This leads to policies like having code reviews before code is checked in, completely bypassing version control, which means code reviews are usually conducted without the benefit of the reviewers actually running the new code.

The polite thing to do here is instead of foisting your changes on everyone, you invite them to take the changes, and they accept when it is convenient for them. You might share several times a day with a colleague or mentor you are working closely with, then less frequently with others working on the same feature, then others working in the subsystem, then perhaps testers, then everyone else.

It turns out that distributed version control is ideally suited to this approach of “politely share early and share often, but don’t push to trunk until it’s solid.” When something as paradigm shifting as distributed version control comes along, you have to reevaluate all your best practices to see if the fundamentals still make sense. You don’t compare a car to a bicycle by seeing how easy both are to push.

  1. July 8, 2010 at 10:05 am

    Apparently my point got lost in the terminology. When I refer to committing here, I’m talking about the centralized VCS sense of the word, where you commit to a repository that is the official central repository for everyone. Committing unfinished, unreviewed code there is impolite, but often tolerated due to centralized VCS not really having a better option.

    People working on a completely different part of the code shouldn’t have to deal with your intermediate bugs. Even though your changes can be selectively backed out, that’s more difficult with some VCS implementations than others, and in the best case it still takes time to isolate the cause of the problem. This causes developers to avoid updating their tree, for fear the next update will break their build and cost them a few hours of unnecessary work, exactly the opposite of the effect you hope to gain by committing early.

    Committing early and often in the decentralized sense of the word, where the only people who deal with your changes do so by invitation, I have absolutely no problem with and actually encourage. This is the right place to get your code reviewed and sort out any merge difficulties, impacting as few people as possible until you all agree it is solid enough to share with everyone else.

    Basically, I’m saying we need to get away from the idea that because sharing early and often is good, forced sharing early and often with every developer on the project is by extension good. With DVCS, the two do not need to go hand in hand.

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: