Git vs SVN A.K.A. Everyone likes control

Hi! Today I’ll try to make an objective overview of both SVN’s and Git’s pros and cons from developer side. I won’t go into depth of configuration of any of them neither will discuss specific commands, but rather functionality itself.

I’d like to point out that the two most famous types of version control systems are:

Centralized version control system – subversion (SVN)Distributed or decentralized version control system – Git

And that’s the big difference, others are just a small smaller things that are based upon this main fact. I won’t say that they don’t matter, au contraire, like French would say, amount of that small things is greater in volume than you’d think.

And now, enough with the “general stuff”, let’s put everything on a list.

SVN is a powerful version control tool and many companies have been using it for quite some time. Over the history, it became the most popular version control system in the world.

The “Pros”

SVN is well-known, wide-spread solution that makes everyone comfortable.Its centralized repository makes tracking simplerThere are only two basic commands (used on daily basis):svn commit or svn ci. This command recursively sends your changes to the SVN server. It will commit changed files, added files, and deleted files.svn update or svn up. This command syncs your local sand box with the server. If you have made local changes, it will try and merge any changes on the server with your changes on your machine.SVN help is more organized and to the point. Even a quick Google search will get you much more simple examples than for Git

The “Cons”

SVN stores a pristine copy of every checked-out source file on the client side, in a subdirectory of “.svn“.Space requirement is much greater than with GitRequires Internet connection for many “daily” stuff – which makes it much slower compared to Git

The “Pros”

Stronger branching than any other Source Code ManagementFaster than SVN (in this example) – mainly because it does common tasks like “diff” locally, which includePerform a diff.View file history.Commit changes.Merge branches.Obtain any other revision of a file (not just the prior committed revision).Switch branches.Smaller complete “filesize” of repository

The “Cons”

Overkill on documentation (IMHO) – can’t easily find small examplesIt can get difficult to track branches and revisions

Although SVN is the popular choice, I’d go with Git any day. Not because I’m geeky (and Git would fit into that perfectly), but from the developer side. The fact is that when using version control system, you’ll mainly do a “push”, “pull” and “difference”. And If it has to be directly on server, it will get lagged sometimes (depending on the changes and connection). Git’s capability to create number of “commits” locally and putting it to server with one push is great. Combined together with “difference” locally its my choice of tool. Solely on those two facts.

On the other hand – you will hear that some clients require SVN, and you’ll almost never hear that kind of request for Git – that’s true. But you can always use SVN for specifics, and Git for your comfortability on other projects. And another relevant fact – when I looked into material for this article – I almost couldn’t find an article “SVN over Git” – it was the opposite way.

To “conclude the conclusion” – small example from “real life” I found on the Internet:

For example the Mozilla repository is reported to be almost 12 GiB when stored in SVN using the fsfs backend. Previously, the fsfs backend also required over 240,000 files in one directory to record all 240,000 commits made over the 10 year project history. This was fixed in SVN 1.5, where every 1000 revisions are placed in a separate directory. The exact same history is stored in Git by only two files totaling just over 420 MiB. SVN requires 30x the disk space to store the same history.

As this is exclusively my opinion, I’m very interested in yours. Please express yourselves!

Cheers! 

To post code in comments, place your code inside [code] and [/code] tags.

View the original article here