CSE 403 student quotes about version control

Here are some quotes from CSE 403 students (in Winter 2011) regarding version control. Some teams reported suffering few version control conflicts, but most reported a significant number. Good management will help you avoid most conflicts, but a tool like Crystal will help you avoid even more. We recommend both.

• “We did not use Crystal. We thought that our development method wouldn't cause us to run into enough conflicts to make it worth it. We were mistaken.”

How often did conflicts occur?

• “We ran into conflicts maybe twice a week before beta and nearly every commit after beta.”
• “We ran into conflicts extremely often, if we were working together or at the same time it was inevitable that the repository branched.”
• “ALL THE TIME”
• “about every 5 to 6 commits is a conflict”
• “twice per week, even though I was pulling every 10 minutes”
• “1/10 times committing”

Did you ever have to throw away changes because of a conflict?

We strongly recommend learning a merge tool before you have to use it. If you have trouble, don't panic; instead, get help. Thanks to the history saved by distributed version control, you can always abort the result of a merge operation and try again (possibly using a different merge tool).

• “Yes, there were times that merging was such a pain that I just reverted back to the original and then rewrote my code. ”
• “Yes. I wrote some code, tried to pull and merge, got really confused by the merge window interface, gave up and deleted my repository, re-pulled, wrote my code again.”
• “Yes. At one point, there was in “irresolvable conflict” in 3 files that caused us to have to revert some changes. ”
• “Many times we screwed up on a merge, and had trouble backtracking through history... some of my commits seemed to disappear when I tried to revert to an earlier revision.”
• “I would frequently create conflicts with myself (working on another machine) and had to throw them away.”
• “Yes. Because merging conflicts occurred and we didn't know what choosing one head over another one would do, we lost the changes of the other head.”
• “I would fail to pull the most recent changes and start working on code that was already tinkered with by other project members, and working through the differences was more hassle than just updating and reworking through code”
• “I was working on code to position the tooltips so that they wouldn't be positioned off the edge of the screen, but before I was able to commit, I saw that this was already done by another member (who committed after I had started), so I decided to scrap my solution.”
• “Yes. One time a commit broke the automated build, so we had to roll back the changes to before the commit.”
• One person said she would lose her changes “when trying to merge or rebase”. We strongly recommend against rebasing.

Note that the same problems would have occurred whether using a centralized version control system such as SVN or a distributed one such as Hg. However, the local history saved by a distributed version control system enables you to choose which version to save, which would have been much harder with a centralized system.

One PM (who also said that she didn't code at all) said the team never ran into conflicts and never had to backtrack or throw anything away, and that SVN worked perfectly. Her team did not have the same experience. This demonstrates how far removed a PM's or non-coder's view might be from reality.