A proposed Subversion vision and roadmap

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

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.