Subversion (SVN) vs. GIT#

These days most developers have experience with GIT and fewer have experience with Subversion (SVN). This chapter is designed to provide an outline of some of the differences between these two source code control systems.

Distributed vs. Central Repository#

GIT is a distributed Source Code Control System (SCCS). This means that there may not be any central repository. Each clone is basically a complete copy of the repository. Once cloned, each repository may branch off arbitrarily from other copies of other repository.

Although there are ways to make GIT function as a central repository these are largely convention and not specifically supported or enforced by GIT.

SVN is a central SCCS. What this means is that there is one central repository from which any number of people may checkout/clone specific revisions from. There is one source of truth for all.

Single Revision vs. All History#

In GIT, when you clone a repository, you get all of the project history. Although this may be handy if you are often bouncing between several revisions without an internet connection, it is very time consuming to perform a clone on a large project and it also takes up a great deal of disk space. This can be a very significant waste of time and disk space if you do not need all of that history very often.

In SVN, when you checkout a revision you get just that --- the revision you asked for. You do not download all of the project's history. You only get the revision you asked for. This is far faster and take up far less disk space.

Switching between revisions with GIT and SVN are equally easy. However, SVN needs internet access to the main repository. Since GIT has a copy of the entire project history, internet access is not needed to switch between revisions with GIT.

With SVN, changing revisions, committing, creating or merging a branch all require internet access to the main repository.

Another difference has to do with backups. If you are performing all of your repository actions locally you must be sure to backup your local system or all of your work will be lost. Since SVN does all commits to the central repository, local backups are not necessary.

So, here are the trade-offs.

Feature                     GIT           SVN
------------------          ---------     ---------
Initial checkout            Slow          Fast
Disk space                  Large         Small
Requires internet           No            Yes
Requires local backups      Yes           No

History#

Through certain operations in GIT, one can change the history of a project. What this means is that you can look back in the past and see a project's history. You can then perform the same operation at a later date and see a different history! What really happened?

In SVN, history cannot be changed and can always be relied upon.

Keeping Multiple Projects In-sync#

In GIT, separate projects are most often kept each in their own repository. One reason this is done is to allow someone to checkout one project without getting all of the other ones. The problem with this is that it becomes difficult to keep one project in sync with other projects.

For example, let's say you have a number of projects that all interact and depend on each other. A good example of this is a web project that contains a back-end and many different front-ends. If you are working on one front-end you may not want or need all of the rest. If you keep them all in the same repository you have to get them all, including all of their history, each time. If you keep them in separate repositories, how do you keep them in sync when you need all of the code at the same point?

In SVN, is is common practice to keep all of your projects in a single repository. This is possible because you can checkout any revision of any part of any project at any point with getting everything. You just get what you want.

Also, SVN keeps one global revision number for the entire repository. This means you always know the exact point of all of the projects at the same time.

Size Of The Repository#

Both GIT and SVN can create branches without copying all of the code in the repository. This means that both GIT and SVN are equally efficient in terms of disk usage in the repository.

Simplicity#

SVN is a simple system. The commands are simple, and understanding history is simple.

On the other hand, GIT is extremely complex to use. It's hard to understand a project's history, and it is easy to get the system all tangled up.

Popularity#

It is true that GIT is wildly popular and SVN is clearly declining in popularity. GIT was designed for large distributed public projects and, presumably, it serves that need well. It is this author's opinion that SVN better serves the needs of the corporate world and that of closer-nit teams far better.