!!! 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.