Fog Creek Software
Discussion Board




How often should one commit code?

This topic was spawned (at David Clayworth's suggestion) off of the CVS rant down the page a bit.

So: how often should one commit code?

Personally, I try and do the following:
* commit after every seperately understandable chunk is completed and works. (for instance, if I'm adding 15 buttons to the toolbar, I'll make a commit for each button -- or each button group if they're grouped by functionality).
* At the least, one should aim to commit once a day (if the chunk you're on isn't done, make it compile and not affect other code until you're done with it and commit what you have so far).

I don't think that there is a maximum though -- as long as the code you commit compiles and works correctly, you should be able (even encouraged!) to commit code in as small chunks as you can.

Opinions?

Steven C.
Friday, April 04, 2003

Your description is geared more toward "released based" software.  In a support type envrionment, I believe commits should be kept to a minimum, OR a distinct branch needs to be created to allow for "emergency production fixes" that would need to go in.

In your example if you added buttons 1-5 then a fix needed to go out, those would have to be resolved. (remove them?  Send them out? etc.)

Mike Gamerland
Friday, April 04, 2003

I'm a big fan of tiny incremental check-ins. Nothing is worse than having to look through a diff with a thousand lines of code, with a hundred tiny changes, trying to figure out why you're having merge conflicts.

Generally, when I'm checking something in, I don't want to have to look through more than 25-50 changes to make sure that the versions merged correctly.

One of my most frequest tasks is editing large (5,000 to 10,000 lines) XML files to set up our software configuration. And, at the same time as I'm editing this enormous file, one or two other people on my team might also be working with the same file. (But we all, for the most part, work on specific portions of the file).

I have come to deeply distrust CVS merges. In my experience, CVS works great with files that are based on lines-of-code. But working with XML in CVS is a nightmare, since the merging algorithm doesn't understand the data structure.

If anyone on our team waits longer than a day or two before checking in their changes, all hell breaks loose, and I have to spend half a day sorting through catastrophic merge conflicts.

Benji Smith
Friday, April 04, 2003

Good point Mike -- in fact, we've been wrestling with this general issue over the last year or so at my company.

I'm not convinced that it means one shouldn't commit often, though -- I think it means that you need to make sure your development branch is always "pretty stable" (by having a frequent automated testing suite), and that your releases are made off a more stable branch. Or something -- thoughts?

I mean, to be honest, I'm not sure how shipping something with my 5 out of 15 new buttons is any worse than shipping it with all 15 new buttons, which QA may or may not have signed off on. In either case, the developer is working on something which could ship at any moment -- which is maybe not the best idea?

Steven C.
Friday, April 04, 2003

A task climbing my list is to modify my UnitTest to commit my changes if the unit test passes.  The interval between tests is on the order of minutes.

Danil
Friday, April 04, 2003

Whenever it goes insane, it should be committed

Mike
Friday, April 04, 2003

Dammit, Mike, that's what I was gonna say. :)

Martha
Friday, April 04, 2003

If the app doesn't quit, you must commit.

Seriously, while I prefer frequent commits, the tools around CVS don't support that model well.  WinCVS, the most popular front-end, has a bad GUI bug that makes its tree display hard to use when there is a lot of vertical space in the tree window -- basic scroll bar issues.  This actually is more of a problem with frequent tagging than committing, but it does make my life more difficult.

I think it would also be nice if you could easily take a series of commits and "combine" them into a single change.  That would allow small incremental commits in what you're actively developing, but let you have more structured change control for your history.

Ben Combee
Friday, April 04, 2003

TortoiseCVS is so much better than WinCVS. Get the new religion. Shell extensions are your friend. :)

As for the "fixing production code" issue, that's a non-starter. Are people really releasing code without labeling the tree, so that they can go back and branch from the release point? I'm not sure whether Mike is thinking that you shouldn't commit until you're ready to release again, or that you should roll new features into your emergency bug fixes. Either way, I couldn't possibly disagree more.

Brad (dotnetguy.techieswithcats.com)
Friday, April 04, 2003

As long as it doesn't break the build, I say commit as often as possible.  Also, control-s is my friend.  I just think its better to be safe then sorry.

Vincent Marquez
Friday, April 04, 2003

"One of my most frequest tasks is editing large (5,000 to 10,000 lines) XML files to set up our software configuration. "

Manually editing 10K lines of XML? If that is one of your most frequent tasks, you could do yourself a big favor by writing a GUI utility to parse and write the XML so you don't have to manually edit tags, and/or storing the config data in a set of database tables from which the XML is then built.  The database tables can even store the version numbers so an SQL query can report the differences.

My situation is similar, in which I have to maintain over 100 small XML files.  It was a huge pain until until I wrote a front-end to remove 90% of the need to manually edit the XML.

T. Norman
Saturday, April 05, 2003

T. Normon said: Manually editing 10K lines of XML? If that is one of your most frequent tasks, you could do yourself a big favor by writing a GUI utility...

Yeah. Tell me about it. I would love to have a GUI front-end on this stuff. The trick is that we're using a special (read:legacy) schema that isn't 100% well-formed. So, it will break in a normal parser. Our engineering department uses an in-house parser that is tightly integrated with our application, so I'm not sure if I could pull it out to re-purpose it for a GUI.

Benji Smith
Monday, April 07, 2003

Of course, even if I had a GUI to edit the XML, that's not the point. I can edit the XML just fine on my own, but checking it in to CVS often creates merges that are full of unreported conflicts. What I really need is a source repository that understands XML and knows how to do diffs of the tree structure.

Benji Smith
Monday, April 07, 2003

Thanks for the new thread Steven.

My problem with frequent commits is that we have a compulsory code review before every commit. Also we have a test suite that is not trivial to run (yes I know, we should make it easy - just trust me, there are reasons).  If we committed several times a day we would have to drag a developer off their work to do a review several times a day. Again we need to build on multiple platforms before checking in. Our build times are long enough that you don't want to do that many times a day.  Yet again, unless you have a complete copy of the source checked out, then every update to the central build may force you to stop your developing and make some changes just to keep up to date with the state of the central code.

If your builds and tests are really quick and easy, and you don't do reviews, I can see that there is no top limit to how often you should check in. But our overhead for making a check in is too high for that .

David Clayworth
Monday, April 07, 2003

You *should* be using labels for this.  Each time a testable code requirement is required, you cut a label with a target date.  Label all code specific for the label requirements and create a build and begin testing.  Only update the label as necessary to incorporate changes which target the labels specified requirements.

A branch is only required when a bug is found in the labeled code, and needs to be addressed for that specific release.

Everyone is free to check whatever they like into the "tip" of development. No one expects the tip to represent anything but untested (and even uncompileable - if you like, culture dependent) code.  If you want a stable build, you sync to a tested label.  This way, no work is lost, and no duplicate or off-project areas are required.

This is such a simple and tested technique.  Yet I am surprised at how many large projects fail to use it.

Nat Ersoz
Monday, April 07, 2003

Untested I'm okay with, but uncompileable just isn't workable for some SCC systems, especially CVS (besides which, how hard is it to make sure you code compiles, even if it doesn't work yet?).

Brad (dotnetguy.techieswithcats.com)
Monday, April 07, 2003

CVS isn't known for its ability to perform merges - especially between branches.

There are quite a few good alternatives out there and spending a bit of money can be a very good investment.

I find that regular small checkins are an excellent idea and haved saved time and effort many times. If it's released code, then I would work on a seperate bug fix branch and still make many small changes - just one big propagate when it's ready for release.

There's an excellent SCM patterns book just out with Brad Appleton one of the co-authors.

Robert Cowham
Tuesday, April 08, 2003

The word before tip is not  'rubbish' but 'build'. 

Good CVS hygeine is critical, pull and merge before you commit.  If it doesn't belong in the tip, don't put it there, if it doesn't belong in the branch don't put it there either.  If you haven't tested it, don't put it anywhere.

Simon Lucy
Tuesday, April 08, 2003

*  Recent Topics

*  Fog Creek Home