Re: switching to SVN ?

[Thomas Schwinge]

Hello!

On Wed, Aug 08, 2007 at 10:11:53PM +0200, I wrote:
> I don't have the time at the moment [...]

Today I didn't really have the time either, but as Marcus yesterday
already started making fun of me after I had sent my previous email, I
thought I'd write down and present some real world arguments why I think
that using a distributed revision control system (like git) is better
than using a centralized one (like cvs and Subversion).


Repository size.  The following data is for glibc, because I have both
cvs and git checkouts sitting on my disk.  The data for Subversion is
interpolated from the data I gathered from the Subversion GCC
repositories.

cvs: 130 MiB.
svn: 260 MiB.  130 MiB working copy plus 130 MiB ``svn data''.
git: 355 MiB.  130 MiB working copy plus 225 MiB ``git data''.

Cost for five separate working copies on your disk:

cvs: 5 * 130 MiB = 650 MiB.
svn: 5 * 260 MiB = 1300 MiB.
git: 225 MiB + 5 * 130 MiB = 875 MiB.

git can locally share the ``git data'' between independent checkouts, I
don't think svn is able to do that.

What does this provide?

cvs: Just the plain working copy.
svn: Working copy plus ability to diff against and revert to the last
     upstream repository revision.
git: Working copy plus _complete_ (as far as I know) project history
     (starting 1987, all branches, 63370 commits on HEAD).

You may say that with cvs and svn you also have access to the complete
history, but that is only with doing network connections.  And this is
rather slow.  At least when doing it from Germany to the U.S.A.-based
Savannah servers.  And especially if you do it in a repository that is
retrieved though the ssh protocol.  git just is fast as hell.  And still
today: network connections are not always possible.

You may question: ``Who needs five checkouts of the same source code?''
I do.  I have five of the Hurd's HEAD, fourteen of GNU Mach's
gnumach-1-branch, four of glibc.  Every one with different patches and
changes.


Another major one.  Ease of creation and merging between different
branches.  (Both long-lived branches (that are kept in sync with each
other) and short-lived branches; called topic-branches principle.)  An
absolute no-brainer with git.  Rather clumsy with cvs.  (Samuel
explicitly asked _me_ if I could merge changes from gnumach-1-branch into
his Xen branch.)  I don't know about Subversion, but suspect it's similar
to cvs.


Obviously: using a distributed system brings the advantages of using a
distributed system, for example: everyone (also people that are not
members of the project) can publish their own branches.  Publishing ones
own changes is -- of course -- also already possible with cvs, but then
you are either (a) operating on a completely separate cvs repository
(development history won't be merged and will be lost when merging the
changes back into the main repository) or (b) do it by publishing patch
files (also losing the history of the creation of the patches), which
tends to be rather clumsy if development is at the same time continuing
on the master repository.


<http://keithp.com/blog/Repository_Formats_Matter.html> also is good
reading in my opinion.  (And I still like this one ``I know Git suffers
from its association with the wild and wooly kernel developers, but
[...]''.)


But of course, I will as well bow to other opinions if there is a solid
consensus about what to do.


Regards,
 Thomas

signature.asc
Description: Digital signature