Jeremy,

I agree with you but what if it doesn't build. We had a situation come up last week where a developer checked in code that didn't compile because he hadn't checked in a week. I'm glad he checked in his code but not if it doesn't compile.

Kyle,

I usually throw them out the window. :-)

Not checking in a week is a HUGE time not to merge with the rest of the team.

On average, we have about 3 - 7 (significant) commits per day per developer. It also keeps us honest, by making sure that we are never in la-la land with regard to the code stability.

Jeremy,

Couldn't agree more.  I always try to check in upon leaving for the day.  Leaving the office with checked out code leaves me dazed and confused the next day.

You should always try to keep your code in a state that can build.  If you can't get your code to a state that builds at least once a day, you are biting off too much work at once.  You need to work in smaller chunks.

Here are my rules, they seemed to have served me well so far:

1.) Work manageable chunks that allow you to commit often, at *LEAST* once a day.  Greater frequency affords you more opportunity to see how the build and integration tests on your build server run. Of course, there is such a thing as TOO frequent.

2.) If you need to work larger chunks then you should first ask "Why do I think I need to do this?" Odds are, you don't and if you think hard enough, you'll realize that the problem isn't as complicated as you thought (happens to me all the time).  But if you do, then you should branch. The only time this doesn't really work is if you have a refactor that takes more than one day, but less than 2. Your value return on branching is negative or break-even and it might be worth it to just risk a day of no commits.

This is one of the problems I have with using TFS right now.  I check in code every 30 minutes to 2 hours.  Usually not longer than that.  I check in constantly.  There are times during the day where I may have 5 check-ins in a span of 15 minutes.  When your debug CI build is taking 5 and 10 minutes to complete, it slows down your feedback process.  I'm being a bit picky, I know, but I like to be able to check in code whenever I want and get confirmation shortly thereafter that everything integrated well.  By the time a build might finish in TFS, I might have had 2 more check-ins by then.  Luckily though, our TFS seems to be running faster than the 20 minute build times we were experiencing last week.  Not sure what changed.  Its just fickle perhaps.

Agreed. Check in often; it's a must.

So.. how often is often ?

Theoretically, you'd like to write an acceptance test, write a unit test, make the unit test go green... is it good to check in a green unit test (although the acceptance test might still be red) ?

Should your unit of work be the acceptance test level ?

What about refactoring.. since that should take place under a green light.. ?

Personally, I try to check in as often as possible.. definitely at least once a day. I've been through week-long local branches though, and would have had a really hard time checking in more often.

Definitely, if you can't check in as often as you'd like, it probably indicates there's a bad smell lingering in the code base...

.. what's that elusive time limit though ?

F.O.R.

I tend to work/check-in at the granularity of acceptance tests.  Every time I implement enough code to pass an acceptance test (and all associated unit tests) I check-in.  I go into a bit more detail on how i work here: geekswithblogs.net/.../105152.aspx

I agree with the idea of putting the work back into SCM as soon as possible but one has to be careful with the status of the code. Assuming no one wants broken code checked in, I'd conclude we will be using branching or shelving for changes that are expected to span more than one day. That way you can check code external to the trunk and not compromise the build status and avoid the risk of loosing work.

The question then becomes, how often to merge with the trunk. The answer to that question varies greatly from project to project, according to the number of active developers and how active they are. If you're the sole developer working on a bug in an otherwise stable application, it may be perfectly fine to keep the branch un-merged for weeks. In the opposite case, if there is a lot of activity in the application source code, a mere day without merging can leave you on an endless race after trunk compatibility.

I'm curious, what version control systems would you recommend for small (~5 person) team?

Please? <-?

Please! :-)

Yeah, not checking in often runs counter to the continuous integration ideals. I've noticed that if I do so, I tend to break a lot of things when I integrate with the rest of the build.

Small steps, manageable steps -- same with TDD/BDD. Yay!

With regards to the question of not checking in because you have broken code; TDD would recommend that you don't bite off anything that would take you more than about 30 mins  to implement. If you are working in larger chunks your tests will be too coarse-grained and you won't get the design benefits you are looking for, and will find your tests hard to maintain because they probably have to test a lot of conditional behaviour in the behaviour under test. If you can't get your small chunk of code working in an hour, you might want to discard it and start again as you obviously did not understand the problem.

If the build is broken no one else should try to check in, so at a certain point a broken build should stop being an individual's problem and become the team's problem.  We would tend to use the day threshold here. If the build is broken for more than a day, then the whole team needs to down tools and address the issue. That may be too long.

The rule I recommend for my development teams is to check in code at least twice a day - at lunch and before going home.  For developers doing TDD, a more real-time model usually replaces the batch model and the question becomes, when are check-ins done too frequently.  There are three reasons I push this approach.

The first reason is that someone may have to unexpectedly miss some days at work.  There are various reasons: illness, children's illness, snow days, issues with parents or extended families.  I dislike having to use administrator mode to unlock files so the rest of the team can proceed.

The second reason is that I encourage the use of rollbacks for development.  There are times when we go down the wrong path and rather than trying to edit everything back to a known state, it is much easier to roll back to the last saved copy.  Saving frequently minimizes the amount of lost work when rolling back.

The third reason I push for frequent check ins is that it gets the code in front of the rest of theam as soon as possible.  This way overlooked capabilities or operating modes can be uncovered by the rest of the team and the code is available for refactoring and reuse.

Track your progress.  If you have been working for four hours without checking in, that is a good indication that you are not making progress with your current approach.  Consider rolling back and starting fresh rather than to continue to thrash.

I think I may have found a source control tool that makes this issue virtually disappear. See this JDJ review of Accurev and let me know what you think:

java.sys-con.com/.../232098.htm

Here's what I do with Subversion. I work during the day on several things. Usually one thing leads to another, so during the day my local project might not be clean. At the end of the day I try to wrap it up. Then I commit it in chunks. The problem is I don't always know what files to commit together to keep it clean, so sometimes I commit a change, but not the other files that were also changed to work with it.

I don't see myself committing every 2-3 hours, because during the day my code is not clean. If I can't get it cleaned up before 5-ish, I don't commit. So all my commits are mo-fr around 17.30

One interesting point about TFS.: When code is checked out it is checked out to a workspace related to your machine.  This is essentially a developer branch as you can have multiple workspaces.  (Don't get me started on non-relative paths) Combining this capability with shared check-out and shelving opens up great possibilities (and dangers)

We only have a 10 developer team but we are finding that you really need someone in the role of configuration manager to set policy and track how the version control is used.

My feeling about long check-out periods that this indicates something wrong with the design of the code that people can not work in small transactional chunks.   ala TDD.

It's amazing how the quality of the code can drives the entire development life cycle and/or process.

It&#39;s time for a New and Notable Update when my flagged posts in FeedDemon gets past a screenfull