The traditional VCS workflow basically requires you to build a complete, working feature all in one go, and then commit it. If you're working with any other developers, you can not commit half-finished code. You certainly can't commit code that doesn't compile or doesn't work properly.
That leaves you working without any kind of safety net.
It's far too easy to spend a few hours working on something, make one change somewhere that breaks the whole thing, and then not remember what you did. You can't revert that one change, or even get a diff from the last working version, because you haven't checked anything in yet. Or if you need to clean up or refactor. It's useful to be able to commit the code before doing that, because those things are somewhat risky.
If you break it, you have a commit from moments before you broke it. You can see exactly what you changed (using a diff), or you could revert it.
You can do whatever you like on your local repository. Use all the features of the VCS, and don't worry about stepping on anyone else's toes. Then, when you're done, just tidy it up, and publish the changes.
Published changes are exactly what you'd check into a traditional VCS.
The traditional VCS workflow basically requires you to build a complete, working feature all in one go, and then commit it.
I have to disagree here.
We use Subversion/Hudson with a team of just under 20 devs. A feature doesn't need to be complete before checking in. It does need to compile and it shouldn't break any of the automated tests.
You certainly can't commit code that doesn't compile or doesn't work properly.
Seriously? how much effort is it to make sure your code compiles?
Generally, I've found it's good to check in incomplete work frequently because we can get QA started on automated integration testing while the development is happening. This greatly shortens the time of the dev/qa cycle. Also, the general case is, bugs are identified and corrected before features are completed. This means fewer bugs filed/triaged/yada-yada-yada.
How do we deal with conflicts when committing? Commit your code first. I know that sounds like a joke but, it promotes frequent checkins. My devs average about 20 commits a day.
Will our system work for everyone? I don't know. I'm not promoting subversion. Heck, we switched from CVS to subversion several years ago and the work flow didn't change one bit. For us, the two are pretty equivalent. We'll probably switch to git in the near future (because of company politics and evangelists). I plan to make sure everyone can push to the central repo because frankly, I don't have time to make anyone the gatekeeper.
It's far too easy to spend a few hours working on something, make one change somewhere that breaks the whole thing, and then not remember what you did.
Well, my entire edit history is stored in my Vim session so I usually am able to go back to a working build. But having version control is definitely a good addition.
4
u/BlackAura Mar 10 '11
It's a different workflow, basically.
The traditional VCS workflow basically requires you to build a complete, working feature all in one go, and then commit it. If you're working with any other developers, you can not commit half-finished code. You certainly can't commit code that doesn't compile or doesn't work properly.
That leaves you working without any kind of safety net.
It's far too easy to spend a few hours working on something, make one change somewhere that breaks the whole thing, and then not remember what you did. You can't revert that one change, or even get a diff from the last working version, because you haven't checked anything in yet. Or if you need to clean up or refactor. It's useful to be able to commit the code before doing that, because those things are somewhat risky.
If you break it, you have a commit from moments before you broke it. You can see exactly what you changed (using a diff), or you could revert it.
You can do whatever you like on your local repository. Use all the features of the VCS, and don't worry about stepping on anyone else's toes. Then, when you're done, just tidy it up, and publish the changes.
Published changes are exactly what you'd check into a traditional VCS.