What are some concrete business cases for a CVS to Git migration?

Question

I have been asked to justify moving a small team over to git from CVS/SVN.

So far, from my reading, I can identify three key benefits:

• Speed
• Easy branching
• Distributed
• More features that SVN just doesn't offer (partial file commits, staging etc...)

Speed

There are some arguments in favor of git because of its speed, however, a common respond to mentioning Git's superior speed is that the difference between 3 and 13 seconds is negligible.

A real life example:

I do a load of work during the day and commit the stable stuff in the evening before I go home.
On a big commit, where I have added several hundred files as well as changed, moved and re-factored existing ones, CVS will perform the commit before I can put my coat on and tidy my desk. How would this be different with git?

Easy branching

Git's branching is lauded by many as one of it's strongets feature. However, branching in CVS/SVN seems to be sufficient to many engineers, especially with modern IDE that make the entire experience and workflow almost identical irrespective of which RCS is actually used.

When I want to try out an idea, I right click my project node in Eclipse, select "Switch to different branch", select "new", type the name and I'm away, committing and updating without 'polluting the mainline' as CVS apparent does. When I have decided that the new ideas in this branch are stable and good, I right click the project again, select "merge with another branch or version", select HEAD and we are back in HEAD but with working changes implemented... How would git improve my experience?

Truly distributed

The main advantage in using a distributed RCS seems to be disaster recovery. However, similar properties are inherent in CVS and SVN as well. This is particularly the case for standard practise usage:

Now I consider it standard practice for the first thing to do in the morning is check the repository for any changes made over-night and do an update/merge if needed so, should I go home tonight and find my repository has been burnt to the ground in the morning, I would of lost...well...nothing. I would create a new repo, commit my local files to the server, the other 5 employees would do the same, there would maybe be a bit of merge fuss but no more than there would of been had we of been committing our local changes to an already existing server and we are away once more. No big deal.

GIT Staging

Another feature that is often mentioned is the staging area. This has no equivalent in SVN/CVS and allows a developer to 'craft his commit' to include on the files you want. 

Often, when this is mentioned, I simply think of changesets. How is the staging area different?

---

Indeed, I even see some disadvantages of using Git:

• Local commits mean that the likelyhood of loosing code is greater, as my development machine is much more vulnerable than our SVN server, and my work is at risk before I push it to our common repository.
• Offline working has no perceptible advantage, since most developers will never work on a project while offline.

I feel as though I must be missing or misunderstanding something fundamental about git and am having a hard time justifying the business case for the switch. I would greatly appreciate your input to better my understanding of the issues involved, especially if you can you identify concrete use cases where git would be a fundamentally superior solution than CVS/SVN rather than simply an incrementally better one?

Answer 1

To hit your high level points head-on:

1. Speed is icing on the cake
2. When people say "easy branching", what they actually mean is "easy merging". CVS just doesn't really do merging, and the Subversion developers have acknowledged that its approach to merging is crap, and that it's staying that way.
3. Staging, partial file commit, etc. These are occasional conveniences that are a consequence of how Git supports merging. Again, not what I consider a 'core' advantage in itself.

To understand the real advantage, it's that Git lets you stop fiddling with the mechanics of wrangling bits of code to and fro, and focus on what code you want where. This is exemplified by the development of the stable kernel versions, and various long-lived feature branches. The hard work for the developers is deciding what code to incorporate. Once that decision is made, the mechanical process of doing so is handled by the computer.

One of the very simplest things that is problematic on CVS with multiple branches and is trivial in Git is fixing a bug or propagating some other change across multiple branches. Suppose you make a change on your mainline, or in one customer branch. After some QA and field testing, you decide that the other 3 customer branches should get the fix too. In CVS, that's a process something like

1. cvs log the fixed branch to identify the revisions A-B that fix the bug
2. cvs diff -rA:B > bugfix.patch to save the changes so that you can reapply them
3. cvs update to another branch
4. patch -p1 -i bugfix.patch to apply the change
5. cvs commit to record the change.
6. Repeat steps 3-5 for each branch to be fixed.

Steps 4 and 5 are rather error prone, especially if there are merge conflicts. Unless you're very disciplined, there won't be a record of where the bugfix happened first, or anything easy to correlate it to other branches. Note that steps 1, 2, 3, and 5 all involve talking to the server, which to someone used to Git, seems glacially slow.

In contrast, with Git:

1. git log the fixed branch to identify the revision(s) C that fix the bug
2. git checkout a branch to fix
3. git cherry-pick C to apply the fix.
4. Repeat steps 2 and 3 for each branch to be fixed.
5. git push

The cherry-pick step will record what commit the bugfix came from in the commit message, so that it's easy to find later. If there are merge conflicts, you will have to resolve them the first time, but Git's 'rerere' (REpeat REmembered REsolution) will automate it for you after that if it's the same conflict, sparing you the chance of mistakes. Only step 5 in this process involves talking to the server, and it's quite fast, because Git knows exactly the minimal data it needs to send over the wire.

For new feature development, Git offers even more power. You can do your work on a branch, without risking messing other people up with your work in progress, and then when it's done, merge that branch to wherever you want. This is the real power of Git, that people who've only used CVS or SVN don't appreciate. git merge actually works, and works extraordinarily well. If you want that feature on several branches, you can merge it to each of them, and history will accurately reflect that they all descend from that one feature branch.

Answer 2

If you have worked with git long enough, you'll start to realize it is in fact more convenient. I haven't had any experiences with CVS, but I had with SVN (whose motto is "CVS done right").

First of all, Git's distributed nature is indeed a blessing. You won't work for a week without pushing your work to another repository (say GitHub), so you don't really lose your work if something happens to your computer.

What you said about "if my repo died, I would create another one" has one problem. You lose all your history! That means all your previous commits, releases, etc are gone. It's not as comfortable as you think.

Also, you commit once a day, while many of us perform many commits a day. In fact, many smaller commits is much more manageable and easier to revert in case of error. With Git, every commit is fast. With Svn, all of them go through network and ssh which take a bit more time.

There are other stuff that are not so convenient with centralized repositories. For example, if you have a directory of versioned+unversioned stuff, renaming that in Git is simple. Renaming it with svn requires you writing the whole address of repository (twice) to avoid mistakenly versioning the unversioned files. And that ALWAYS comes with a commit. If you are reorganizing a few directories, you have as many useless commits.

In SVN, if you add a few files and commit, then do an svn ls, you don't see the new files unles you svn update. But in Git, since you own the repository, such things are not necessary.

In the end, all of them work, so you can't find a major flaw in any so you could move away to another. However, it's a matter of convenience (at least for me). If you program for windows, of course you can do everything, but once you do the same in Linux, you feel much better because a lot of things make more sense. Like I said, they all work, but some have a better design. I believe that is the case with Git vs CVS or SVN.

---

My suggestion is, give Git a try. Work with it for a while. Try its different features and in a few months you will come to a conclusion whether you like Git better or CVS.