I consider this the golden rule of source control:
Check in early, check in often.
This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2008/08/check-in-early-check-in-often.html
This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2008/08/check-in-early-check-in-often.html
If you DO have a team environment, and ARE supposed to be using a repository, I whole heartedly agree… anyway, I skimmed your article.
I hope to get subversion setup ASAP in my small shop. Life has been sucking lately, without it.
If you DO have a team environment, and ARE supposed to be using a repository, I whole heartedly agree… anyway, I skimmed your article.
I hope to get subversion setup ASAP in my small shop. Life has been sucking lately, without it.
I support the idea of check in early somewhere with both my hands and both my feet and my dangling monkey tail. But I have reservations about merge early. Why? Because it limits testing. If everyone checks in whatever they feel like in the trunk, you can only test the code after the code freeze. Before the code freeze, there is no good state of the code, and you’re not only testing your changes, you’re also testing everyone else’s changes. (I know that your unit tests will test your code, but they will not test how it interacts with everyone else’s code.)
This sounds like a nightmare in the environment I work in. We’re using SVN and I’m pretty happy with it. The problem is we often have to merge a new feature or change to another, or multiple branches. The way I do things now, I make one big atomic commit once the code is perfect, then when I have to merge it into two other places, it only takes me a couple of minutes thanks to atomic commits. One new feature equals one commit. Now imagine if I had to merge 30 tiny changes to two branches? 60 extra merge commits. Sounds like a late and miserable night. I’ll sometimes get three requests to merge code to other branches in one day. Now imagine I each of these features/fixes constituted 10 to 50 individual commits. If they’re not sequential (and they won’t be) I’m looking at an average of 120 individual dry run, merge, and commits. Often across multiple projects and branches.
NO THANK YOU.
I once had a disagreement with The Jerk, some newbie wannabe manager with a still dripping diploma from somewhere. The Jerk was trying to get all pompous and tell some younger guys that they must check in everything each day. It was policy. As long as it compiled we’re all good.
Not sure where The Jerk pulled that rabbit out of, because it couldn’t be farther from the truth. I think he then tried to misquote McConnel, but I own Code Complete too.
My response, tempered by some years of experience, was:
- break jobs into as small a chunk as possible that still makes sense and produces useable code.
- if it doesn’t work, don’t check it in.
- if it’s not cleaned up, don’t check it in. (commented correctly, good names, etc)
- merge from the main trunk at least 3 times a day, if not more.
- merge from the trunk before you check in
- communicate a lot, especially if you’re editing the same classes as someone else.
- if you’ve been off the radar for a week, you’re taking far too long.
The Jerk talked about getting hit by a bus, etc. I said who cares about code if a guy’s in hospital or there’s a war, we’ve got better things to worry about than a few days of lost code.
I feel the pain. I do. I understand. I get scared. I want to check in early and often, but source control isn’t your personal unlimited undo. When I look at history I don’t want to see rubbish. I want to see snapshots of working code.
Don’t hold back, and don’t go dark, but use your f’ing head. It’s far better to locally integrate multiple times per day and merge back after a few days because guess what, no surprises.
Some things just take time, and my driving rationale was to be able to ship anytime. If you always try to keep the code in source control golden, it staves off the effect of code rot. If you check in daily because The Jerk tells you to, then you start taking shortcuts, and you forget things. You start to not edit other peoples code because maybe they’re still working on it.
FYI We did TDD and used Cruise for continuous build, and tried to stick to an agile-like process, and typically it would be multiple features per day checked in per person. You sometimes need to change the process of feature granularity to solve forest/tree problems elsewhere.
Whether you use DVCS or a centralised system with branching, you can check in code that doesn’t even compile, yet alone run or even pass its tests, and not break anything because noone is forced to get a copy of that code.
But if you pick either option, then people can choose to take a look any time they choose to do so, and you can put your code into the main branch any time it is compiling and working.
If you can’t do distributed and you can’t do branching, well, ok. Sometimes it’s important to remember that a rule is actually just a guidline and carries the implicit assumption that you won’t be a deliberate moron just so things will go wrong and you can blame the guy who wrote the rule.
And your repository history is a pretty poor system to use for tracking your list of new features for the marketing department. Sure, you’re embarassed that the record of the two days you spent not seeing that semicolon are recorded for posterity, but if people are going to use your repository history as a weapon, you’ve got much more important issues to worry about - such as updatign your resume.
Here’s my little bit of code to check in, and then add to:
C (this is a comment in FORTRAN, but only if the ‘C’ is in col 1)
Recently I got into the habit of typing hg init as the first thing when starting a project, even when the project is a small script I’ll probably spend an hour coding and use a dozen times before throwing away.
(that’s mercurial command for create empty repository here)
T what the hell are you talking about? In SVN you merge revision ranges, not individual changes.
Who said anything about the repository being something for marketing?
It’s death by 1000 cuts if you have to look at source control changes and determine if the code is meant to be done, or it’s just essentially a checkpoint mid-edit. I’d just rather know that if it’s checked in, it’s supposed to work, and is supposed to be done. Sure it’s not always the case, but it’s better that nothing if that’s the goal.
Commenters are mixing concepts up. Don’t check in broken code. Don’t wait until you’re done. Just check it in when it’s close to how you want other coders to see it. When your class is stubbed out. When your functions are declared. When you’ve implemented a sweet ass method… This way, your coworkers can see your though process and the direction you’re heading.
Someone brought up branching. I haven’t worked on anything big enough t o need to branch. Do other contributors actually look at ‘your’ branch? If not, then this doesn’t help, because when they check out the latest version… your changes aren’t there.
I’ve actually worked with people in class who have checked in their code after not updating for a week- then run off to class. breaks keyboard
A nice article, but it applies mostly to centralized version control systems. With DVCSs like hg and git you can pretty much have your cake and eat it too. You can check it broken code as much as you want so that the history is recorded and you can revert when you want and then when you feel the code is good and won’t break the builds, you just push it upstream.
You can check it broken code as much as you want so that the history is recorded and you can revert when you want and then when you feel the code is good and won’t break the builds, you just push it upstream.
I agree that painless merging is absolutely a strength of DVCS but this is also possible via branching and merging in centralized systems:
The flip-side of people that won’t check in are people that won’t get latest, and I think one tends to lead to the other. Small frequent check-ins and getting latest help build a rhythm of steady incremental change (dare I say it…improvement). A dozen or so people who don’t check in for weeks on end leads to integration pain and broken builds, which leads to a fear of getting latest and bizarro bugs you SWORE you fixed weeks ago lingering on other people’s systems. This in turn makes things harder to test and verify - Joe just updated XYZ and we’re seeing that old bug 9876 again on his machine. Hmmm - is it a regression? Was 9876 never fixed properly in the first place? Or is Joe just running a cobbled together frankenstien build of code that is hopelessly out of date?
This is once again an argument for distributed SourceControl (git, mercurial…). You can check in as often as you want (to your local repository) and gain the full versioning over everything you do. You can share it with your coworkers (push or pull the changes).
And once you have running code, you push it into the repository (or branch) that the continuous integration server uses.
The more I use (and get used to) distributed version control, the more I like it! I don’t see any reason to continue using svn/cvs based versioning and I can only encourage everyone to try it out! There is a learning curve (more advanced concepts give more opportunity to failure), but it is worth it.
When I’m developing a device driver, I often go days without a compiling build. You want me to check that in and break everyone? That’s insane.
The only good reason I can see for checking stuff in before it works is so that I personally can go back a revision or two if I delete something I shouldn’t during development. However, you don’t really need revision control for that. A good editor will keep around old versions for you too.
Oh. I am in agreement with the Git fixes this comments too. Unless you are now saying that with Git, I should merge my changes every day. Then you are back into crazy talk.
I’d much rather have small fragments checked in periodically than to go long periods with no idea whatsoever what my coworkers are writing.
Really? Shocker… !! What gems can you pass onto us next?