Home > Distributed Version Control, Software Process > Why the Tip Should Always Compile

Why the Tip Should Always Compile

Having a source control tip that always compiles is one of those software truths that I thought was self-evident, but today was reminded that it’s not self-evident for everyone. I was ready to check an important change, and as per our process, updated to the latest to make sure everything still worked before checking in. As it turns out, the guys one floor up were not so courteous. The build was broken in several places.

It took a few minutes to determine the offender, and I shot him a quick email in case he wasn’t aware of the issue. “Sorry for the inconvenience,” came the reply. “We’re not done checking it in yet.”

Multiple people coordinating check ins can be complicated, so I gave them another hour. Still didn’t compile, but for slightly different reasons. I then had a four hour training class. I came back from that expecting to be able to check in before I went home, and they had made progress but the build still didn’t compile.

At this point it was clear this wasn’t just a matter of coordinating check ins. They were using the main branch the entire building shares to integrate and debug their changes with each other. In case it’s not clear by now why that is bad, we will probably not have a working daily build tomorrow. If we do have a daily build tomorrow, a lot of important changes will not have made it in. Everyone’s testing will be set back by a day because a small group thought they would save a little effort by circumventing the process.

Early in the development cycle, this might not be a big deal, but we are very close to release.  If there’s one thing I’ve learned about software, it’s that integration and debug time is hard to predict.  Don’t ever think “just this once” you’ll check in something broken because you “know” it will only take a few minutes to fix.  Dealing with accidental breakage is difficult enough.  Having an unusable repository for 6 hours cannot be classified as an “inconvenience.”

On the other hand, it’s difficult to blame them for being tempted, given the source control tool we’re using. We’re evaluating alternatives, but in the mean time are stuck with what we’ve got. Take a look at the following characteristics of our version control process. If they look familiar, you might want to consider a version control change of your own.

  • Merging is difficult, so we have one big branch that everyone checks in to.
  • We have rules like don’t check in things that don’t compile, but no technological way to ensure they are followed.
  • We can either push our code to everyone in the building or no one. There is no in between without a lot of manual work.
  • We can check in even if our local copy isn’t updated to the latest.
  • We have no easy way of cherry-picking only code that is known to work.
  • There is no easy way of collecting related changes, then committing them all to the main branch in one operation once they are integrated.

If that list sounds familiar, and you haven’t looked at distributed version control yet, now is a good time to do so. At this point, we are simply struggling to maintain what I consider a bare minimum standard of having a tip that always compiles error free. I haven’t even touched on the ideal of having a tip that always passes a test suite. If your tests are automatable, your tools should be able to be set up to automatically reject changes that cause it to fail, same as a bad compile. If, like us, circumstances necessitate tests being run manually by a human, distributed version control can help with that too, with the right branching model. More on that later.

Advertisements
  1. Matthieu M
    May 21, 2011 at 9:25 am

    The very precise reason why we have a bot (Hudson) integrating our own changes at work.

    When you want to commit, you ask the bot to do so, he not only build, but also runs the whole testing suite, and then, only when the light is green, does it commit the “merged” version onto tip.

    Of course, this implies we had to truly work on making both the build and the testing suite faster so that the turn-around is about 30 minutes…

    But the knowledge that whenever you start developing from tip you necessarily have a working piece of software to begin with is invaluable.

  2. May 27, 2013 at 2:58 am

    What’s up friends, pleasant piece of writing and nice urging commented at this place, I am in fact enjoying by these.

  3. June 9, 2013 at 12:03 am

    Usually I do not read article on blogs, however I wish to say that this
    write-up very compelled me to take a look at and do so!
    Your writing style has been amazed me. Thank you,
    quite nice post.

  4. July 2, 2013 at 6:24 am

    This article will help the internet users for building up
    new web site or even a weblog from start to end.

  5. 20
    September 22, 2013 at 12:03 am

    It’s perfect time to make some plans for the longer term and it’s time to be happy.
    I have read this put up and if I could I wish to
    suggest you few interesting things or tips. Perhaps you could
    write subsequent articles regarding this article. I want to read even more issues approximately it!

  6. May 21, 2016 at 7:34 am

    View the Web for horseback using camps in your location or
    where you intend to vacation, and also you’ll locate enough information to a minimum of get you started.

  1. July 16, 2010 at 12:59 am

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: