Academic Technology Group Developers Blog Education. This is how we do it.

My previous Git vs SVN made some errors based on old information. I’m hoping this will be a more accurate account.

Git Pros:

• DVCS (Distributed Version Control System). What this means is it works off of the idea that every user copies the entire VCS and runs their own repository locally. This has several benefits.
  1. Speed. This makes development/working with the repository much faster as almost every operation does not require you to contact the “primary” repository.
  2. Tiny Commits. This allows / encourages tiny commits, so changes are tracked more closely and can be more easily separated out.
  3. Control over who merges. A merge can be attempted by any access layer, but this will generate a pull request which can then be reviewed and approved.
  4. No network access required.
• Lightweight Branching. While feature branching in SVN is technically possible, it’s also a pain in the ass. Git made branching a first class feature. Easy branching means more people will probably make use of more advanced workflows.
• Much smaller repositories. Due to better compression.
• Repo file formats are simpler. So repair is easy and corruption is rare.
• Clones act as full repository backups. That’s potentially useful I guess.
• Creating a repository is trivial. So people who want to use repositories to track tiny personal projects, can just do so without any setup.

SVN Pros:

• Narrow Clones. You can make a checkout of just one subdirectory deep in a hierarchy, download only the files related to that directory, and still be able to make commits. This seems useful in massively large repositories.
• Authz files are easier (more standard) to write than Git commit hooks.
• Comfort. People are already used to the linear structure and commands of SVN and that makes sense to them. Switching to DVCS is a cost. Most developers find the switch painful because it goes against what they’ve done for so long.
• Deals with binary files better. If you’re tracking massive amounts of non-textual data, SVN handles it better as Git’s compression won’t work as well and it’ll be copying over everything.
• Better classical / hierarchical model. (As opposed to patch/change based revisions.) It keeps in place a simplified model, good for keeping release history. Good for if you only make large commits and don’t want / need to record small dev changes. From a Git perspective, think of fast-forwarding every pull request.
• SVN Lock. This provides more top down control over the repository.
• Supports empty directories. This is probably important to someone.
• Shorter and (mostly) predictable revision numbers.

SVN encourages large commits, Git encourages smaller commits. Simplicity or granularity. We all started out used to the former, but the latter is catching on quickly.

What seems to be the bottom line for most people is that SVN is the old and Git is the new. This is the direction of things, and it’s a new way of thinking about workflows and how VC can actually be doing things OTHER than just storing data.

The only issue that really matters to us is the pain of the switch. The problem is if we don’t understand the benefits that we’re getting from the switch, there’s never going to be enough of an impetus to switch.