• All git operations are performed locally. This means that commits can be made offline, and can be made far quicker. In addition, instead of pushing the entire code, like in SVN, Git only pushes a record of changes.

  SVN response: It's important to optimize things that actually matter: in America, we have broadband and source code is very small making this irrelevant. In countries where bandwidth is limited or sporadic, GIT offers a clear advantage. FYI, SVN keeps pristine copies of checked out code so most common operations such as diffs can be done offline and fast.

• Git can branch and merge far more smoothly than SVN. Last year, we had a number of problems trying to merge with SVN. These problems would have been negligible with git.

  SVN response: GIT branching and merging is more powerful, but is confusing (git push origin master). It is very easy to accidentally push (submit changes) incorrectly and overwrite other folks' change sets; in projects previously run with GIT, CM support costs tripled - and that was with experienced developers using the system

  • The reason Git can merge better than SVN is because Git creates a three point merge, where it looks at the two branches being merged AND the most common ancestor, in order to determine what to change. SVN only looks at the two being merged, resulting in many conflicts.

  SVN response: GIT is better at merging, but recent SVN releases made big improvements over last year's version. GIT merge commands and models are powerful but confusing, when you have a team of very new developers, you have to weigh ease of use and understanding over power tools.

• Git repos are generally much smaller than SVN repos. The Mozilla repo of git is 30x smaller than the Mozilla repo of SVN, even though it's the same size.

  SVN response: modern disks are huge and cheap; this is another irrelevant optimization.

• Git is open source, while SVN is closed source, and this makes the leader of the CM team happy.

  SVN response: this is not true, subversion is open source: ​https://subversion.apache.org/

In order to remain unbiased, here are some advantages of SVN:

• SVN is a more mature project than Git. While this would have made a difference in the past, it only affects the Git GUI, which, given the Eclipse plugin, doesn't matter.
• SVN uses sequential version numbers, while Git uses SHA hashes. If you are using a service like GitHub or Bitbucket (which we will be using, if we swtich to Git), this doesn't matter.

• SVN uses the concepts and language common across all version control systems (except GIT); when you learn SVN, it's easy to understand other version control systems. However, GIT saw fit to use different terminology for most things and even to use common standard terminology to mean different things.
• SVN is tightly integrated with this Wiki allowing you to browse commit timelines, connect submissions to defect reports (trouble tickets), and browse the repositories.
• SVN is well documented: ​http://svnbook.red-bean.com/
• SVN clients work well, particularly those integrated with NetBeans and Eclipse.