Re: fs dump/restore proposal

On Tue, Apr 23, 2002 at 04:43:08PM -0500, Ben Collins-Sussman wrote:
>...
> Two problems we want to solve
> =============================
>
> 1. When we change our node-id schema, we need to migrate all of our
> data (by dumping and restoring).

Yup. This is also a way to garbage collect when we find that some bugs left
crap in the database. (the SVN repos has some garbage; cmpilato found we
double-stored some data a long time ago, and left one orphaned)

> 2. Serves as a backup format. Could be read by other software tools
> someday.

Rephrase as: database-independent, long-term storage format. Berkeley DB or
its future replacements in SVN have their own backup mechanisms. We aren't
intended to replace those. We're looking for a format which is independent
and/or can be used for migration between databases.

> Design Goals
> ============
>
> A. Written as two new public functions in svn_fs.h. To be invoked
> by new 'svnadmin' subcommands.

IMO, they go into svn_repos.h. The FS isn't really concerned with this
information. If we find that the data is just way too tied to internal
knowledge on the dump or restore side, then sure: they can go into the FS.

>...
> - A filesystem is an array of trees.
> Each tree is called a "revision" and has unversioned properties attached.

Note that you should be able to dump -rX:Y. Kind of a nifty way to partition
the database. Or maybe you want to lose a bunch of ancient history:

$ svnadmin dump -r 1000:HEAD > recent
$ svnadmin create ~/repos/new
$ svnadmin load ~/repos/new < recent

> - A revision has a tree of "nodes" hanging off of it.

I'd agree with Branko here on declaring it a DAG or somesuch, so that we can
have hard and soft links in the future.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org