Code Version Control: svn vs git

Get svn
Get git

Pros of svn:

• Good GUI tortisesvn for running svn commands.
• Partial checkout: Choose any sub-dir to checkout as a working copy.
• Centralized server: Save space by maintaining single global repository.
• Portable to Windows and Linux/Unix.
• File-based tracking: More detailed tracking of files.

Cons of svn:

• Centralized server:
  • When the server/network is down or damaged, you cant access your repository, or loss your repository forever.
  • Potential access conflicts to shared files. Frankly, I dont like people manipulating my repository.
  • Flat checkout: Checkout from remote repository transfers file by file, which can be quite slow through the network, especially dealing with many small files.
• Limited move/rename file: You'll need to commit moved/renamed files before manipulating them.
• No good mechanism for pulling or pushing updates to other repositories.
• .svn folders are everywhere in a working copy. Hate this when I want to copy a folder to somewhere.
• File-based tracking: More overhead in tracking.

Pros of git:

• Good GUIs qgit, citool available for visualizing branches and histories.
• Decentralized: If a server is gone, you have nothing to loss in your local copy.
• Space efficient: Single git repository is typically much smaller than a svn repository.
• Compressed checkout: Checkout from remote repository transfers data in compressed format, hence more network friendly.
• Better ways of file moving/renaming/deleting, but this is subjective.
• Simple branch & merge mechanism, for both local and remote repositories.
• Easy branch switching: Short command to switch a working copy from a branch to another branch (with little CPU), requires no folder duplications too. Compared to svn, you need to know which folder to look for for a particular branch. To create a branch in svn, you basically duplicate entire branching folder.
• Requires no user account. Simply publicize your repository, and it's up to anyone to pull your updates. Not really a feature, but git mode of working supports this well.
• Tree-based tracking: For low tracking overhead.

Cons of git:

• Full checkout: Must checkout entire working copy, as well as the entire repository (including all history).
• Multiple repositories: A full repository for each checkout.
• Lonely merging: I have to resolve conflicts by myself when pulling updates from remote repositories. (In svn, the one causing the conflicts will fix the problems.) You can settle conflicts with the authors if you can command them :).
• Use Linux/Unix File System specific features such as hard link in some cases, arguably a pro feature for space efficiency, but trading off portability. Needs Cygwin for Windows, which results in poor performance.
• Missing file-based tracking: Doesn't track file copy operations. We may not know the source copy of a file. It probably takes more time to obtain file specific information, e.g. history of a file.