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.)
-K
---------------------------------------------------------------------
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