GIT vs. CVS vs. SVN

[blu-Z8efaSeK1ezqlBn2x/YWAg at public.gmane.org (Edward Ned Harvey)]

> From: discuss-bounces-mNDKBlG2WHs at public.gmane.org [mailto:discuss-bounces-mNDKBlG2WHs at public.gmane.org] On Behalf
> Of Jerry Feldman
> 
> Our office has been adding some new developers, and I've been asked to
> set up GIT. Fortunately our company supports GIT, but the R&D main
> source control system is CVS. I'm looking for some rational discussion
> from developers who have used both GIT and either CVS or SVN. Linus has
> standardized on GIT for kernel development.

There is no reason to use CVS anymore.  SVN was designed to be a CVS killer,
and they succeeded in doing so.  The fundamental difference between CVS and
SVN is that CVS stores versions of files, while SVN stores versions of a
directory tree full of files.  As a result, SVN has enormously higher
usefulness and features etc that CVS couldn't even dream of achieving.

The fundamental difference between Git, Mercurial, and Subversion is the
concept of centralized vs decentralized.  There are pros and cons of each.

If you have a decentralized versioning system (git or hg), it fundamentally
operates on the assumption of mergeability.  Decentralized versioning is NOT
appropriate if you have a significant number of unmergeable files in your
source tree.  Decentralized versioning is especially useful for projects
which have huge numbers of highly disperse people working on it.  This is
why it's great for the linux kernel.  You've got a team of developers
working on some module... So they're able to rapidly prototype and merge
amongst each other, until they reach a consensus, and then merge their
changes upstream.

Eventually, decentralized versioning must become centralized.  At some
point, Linus asks everyone "Hey you guys, I want to release 1.7.x, so merge
your changes with me now, or forever hold your peace."  This is a manual
process (sort of) so it can become a disadvantage for decentralized
versioning...  If you have regular release cycles, and you don't have
hundreds of disperse people working on a project, then centralized
versioning is probably a better fit for you.

With a centralized versioning system (subversion) there exists a server, and
the server is the "authoritative" copy.  All the developers downloads a
local working copy, and choose to manually sync up & down whatever changes
are made.  If you want it, this gives you the ability to implement file
locking (which cannot be done with decentralized versioning) and this
serializes all changes to the directory tree.  Both of these characteristics
are vitally important for managing unmergeable files.

With a centralized system, there is a clear single point of control, for
administrators to implement backups and security.

So ... pros and cons of each system.  You've got to choose whichever one is
better for your purposes.

Incidentally, commercial versioning systems exist too.  Generally speaking
the advantages of the commercial systems are higher performance, or tighter
integration with specific engineering tools.  For example, if you have a
large directory full of thousands of files...  Whether you use git, hg, or
svn, you will have many operations which must "walk the tree" inspecting all
the files for changes and scanning for updates etc.  This can be a big time
waster, depending on your development team's behavior preferences.
Commercial solutions such as clearcase and perforce are able to eliminate
those, by forcing file locking and centralized management of all updates &
changes.  And stuff like that.  In my environment, this means the difference
between ...  Every engineer wastes 5 minutes every time they check for
updates or do a commit in subversion ... versus ... the same operation is
completed instantly every time in perforce.