Tuesday, December 17, 2013

Git vs SVN




Last friday we had a discussion in our office, which software versioning tool is better, Git or Svn.
I am sure there are quite some discussions around this topic in the web, and the simple answer is as usual: that depends.

This "that depends" is described in more detail in an interessting StackOverflow repsonse. Further I found a comparison on kernel.org quite interesting which I'd like to summarize for my own purpose. The following comparison table should give an overview but doesn't claim to be complete.

GIT
SVN
Architecture
Distributed, Peer-2-Peer topology.
Supports perfectly distributed, autonomous working teams or developers, without permanent network connection.
Centralized, Client-Server topology.
Supports well centrally organized teams with permanent network connection. Backup is easy.

Access ControlNo effective read/write restrictions imposable. (OpenSource Mindset)Fine grained ACLs possible.
BackupBackup required on every repository location.Backup-Strategy only on central repository required
Checkin/CheckoutA complete checkout of the entire repository is always required. Difference between commit to local repository vs. commit to remote repository. Partial Checkout possible, the is only one repository to checkin/checkout
BranchingIs an intrinsic core concept as every repository (clone) is a branch in itself. Supports only single-branch-commit, which is less flexible but more simple and therefore better automatable.Is more flexible and allows Multi-Branch-Commits, but this increases complexity making it more difficult to understand. More conflicts occur that need manual attention.
Binäry files Supported, but some changes might cause a version split to a new file, as the binary change is too big (i.e. increase light values of an image)Supported, versioning is always related to a single file. No "unwanted version split".
PerformanceFast, because most operation run locally against the local repository.Slow, because most operations are performed against a remote server.
Space RequirementsThe repositories itself are smaller, but the more (full) clones exist, the more overall (distributed) storage capacity is required.The central repository might become huge, as the version histories are kept. Client copies might be smaller, as only partial fragments might be checked out.
IntegrationAs it was initially designed for the Linux development community the primary interface is still the command line. Integration to tools or Windows (Explorer) is less advanced and still in development or even not existant.Integration to tools or operating systems (Windows, Mac, Linux) is good thanks to a variety of proven tools, such as Tortoise, Subclipse, Subversive, etc.
VersioningUses SHA1 to produce version identifiers, which are less well readable and not predictable.Uses sequential, increasing revision numbers which are short and well predictable.
Learning CurveHigh, as it requires a paradigm change, there are new terms and concepts. Repository structured might grow complex, weaker tool support. Big and growing community.Low, Proven and well document. Architecture, repository structures and workflows are easier to understand. Good tool support. Big community.
Typical usersTech-savvy, open minded, open source oriented, explorers. Typical early-adopters.Less tech-savvy, conservative, workers. Typical late followers.

Concluding, the preferred tool depends on the scenario respectively the requirements it should serve.

If you have situations where checkin/checkout mechanisms are required when no internet connection is available, or you have distributed developers or autonomous, self-organized teams (like in Scrum), and the rest of the infrastructure (build, deployment) does support that mode of operation - Git will be the tool, as the advantages outweigh the disadvantages.

If you're not a typical early adopter (that means, are not open minded enough to embrace new paradigms), have a centralized infrastructure (build, deploy, backup), work typically at or close to the same place with always-connected network availability, and work most of the time on Windows - stick with SVN, as the advantages of Git have no effect and the disadvantages outweigh.

I for myself have never worked with Git before. The companies I have worked for typically used a centrally organized repository, which was not always Subversion (ever had the joy of working with Integrity MKS?). For my personal open source projects, I prefer SVN simply out of habit.

What do you think of it? Let me know.
Post a Comment