Feature request: a real backup/restore system for svn.

After fighting with issue 1817 for a few days, Karl and I have come to
the conclusion that 'svnadmin hotcopy' is a mess, and we should
deprecate it.... that is, remove it altogether in 2.0. Here's why:

  * it has a race condition with db logfile autoremoval, which is
    something that people have really come to depend on. In theory,
    the worst thing that can happen in the race condition is that the
    user sees an error and just tries 'hotcopy' again. In practice,
    who knows? We've not done any real stress-testing.

  * it's completely specific to BDB. fsfs needs no such thing, and a
    future SQL backend will already have its own tools for backup.

  * people currently view it as "the correct way" to make a full backup.

We think that Subversion should provide admins with a single, robust
backup/restore solution which "just works" (won't throw random retry
errors), and is independent of repository back-end. We're probably
talking about a smart script which

   * utilizes 'svnadmin dump/load' as the main mechanism for backup
     and restore,

   * knows when to use --incremental or not,

   * uses the 1.1 --deltas switch for dumping,

   * remembers what it's done before, and manages a collection of full
     and incremental dumpfiles,

   * can intelligently restore from the collection of dumpfiles.

I'd like to file this as a feature request, but I thought it made
sense to run it by the list for opinions first.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jun 17 18:14:44 2004