A proposed Subversion vision and roadmap [LWN.net]

A proposed Subversion vision and roadmap

Posted Apr 4, 2010 6:05 UTC (Sun) by emk (guest, #1128)
In reply to: A proposed Subversion vision and roadmap by cbcbcb
Parent article: A proposed Subversion vision and roadmap

1. A central server is required as the one which is stored on fully backed up storage. (yeah yeah, DVCS means there's a copy on everybody's desktop. All in the same building. Real backups are off site)

I've managed offsite backups for both Subversion and git, for repositories in the 320GB range. In my experience, reliable Subversion backups require a script to hotcopy the entire repository, and a fresh whole-repository backup using a full-fledged backup system. This tends to cause minor headaches for incremental backup systems.

Git, in contrast, can do very fast incremental backups via cron and git pull. Even better, it can trivially verify the integrity of a repository by checking all the hash sums.

Now, there are drawbacks to using git for certain kinds of large organizations. Git submodule support, for example, is pretty arcane and requires a moderate level of git-fu. But from a backup perspective, I'd rather use git than subversion any day of the week.

(Log in to post comments)

A proposed Subversion vision and roadmap

Posted Apr 5, 2010 14:51 UTC (Mon) by Thalience (subscriber, #4217) [Link]

I'm pretty sure the charge is that using "svn dump" in this way is slow, and a (minor) hassle to set up.

A proposed Subversion vision and roadmap

Posted Apr 5, 2010 17:45 UTC (Mon) by emk (guest, #1128) [Link]

svnadmin dump requires a complete copy of the entire repository in each
daily backup. (And, IIRC, dumps are frequently larger than the original
repository.) Once repositories reach a certain minimum size, this adds
considerably overhead to daily incremental backups.

svnadmin hotcopy produces an exact copy of the repository. If you're
using fsfs as your storage backend, Subversion never updates the files
that represent each commit, so incremental backups will (1) look at every
file in the new hotcopy, and (2) eventually decide to only back up the new
ones. But for the size repositories we generally used, this whole process
would take about an hour, and bring the Subversion server to a standstill.

git backups require a 1-line cron job that calls 'git fetch', and generally
completes in a few seconds. And git has the ability to rigorously verify the
integrity of a repository.

So given a choice, I'd _much_ rather manage backups for a git server than
a Subversion server. And that's not even counting the fact that git
repositories will generally exist on many development machines, laptops,
etc., and so even the sloppiest of organizations will almost never loose
data.