[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: fs dump/restore proposal

From: Karl Fogel <kfogel_at_newton.ch.collab.net>
Date: 2002-04-24 05:13:43 CEST

Greg Stein <gstein@lyra.org> writes:
> Absolutely. I think all the items should be tagged in some way; I would
> suggest RFC822-style headers. In fact, you could also use the "extra newline
> separates the header from the body" thing, where the body stores the
> fulltext. And note the length of that using a Content-Length header... :-)

I think this would be obviated by Branko's suggestion to completely
separate metadata and data. I assumed he meant something like

   - put all the metadata in one big XML file, that uses unique IDs
     (constructed to be automagically XML-safe) referring to...

   - ... actual data files, or data segments. If we use files, then
     the actual dumped object can be a tar tree, and we get the length
     counting for free.

> Re: binary format. Branko suggested using base64. I'd suggest that we not
> bother with the import/export overhead of that, and stick to a simple
> length-defined binary format. An external tool can always convert to base64
> if that is important. (or convert to XML or whatever...)

See above.

> Re: avoid diffy. Yes. Fulltexts are nicer than diffs, and I like Zack's
> suggest of using a compressor. But the compression should be relegated to an
> external tool; I don't see a need for SVN to actually product compressed
> data. It ought to be something like:
> $ svnadmin dump ~/repos/test | gzip -9 > svn-repos-test.gz

.tar.gz. :-) ?

> Re: multiple files (e.g. one metadata plus one or more content). Bleck. That
> makes it really hard to deal with the thing. For example, the above command
> line just piped it all through gzip. If you had multiple files, then you
> couldn't do that.

I don't see anything wrong with multiple files, as long as they are
packaged up in one blob for transport, and unpack to a single tree.
(At least, the objections above don't seem to apply to that kind of
tar file.)


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Apr 24 05:11:36 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.