Ben Collins-Sussman <sussman@collab.net> writes:
> Implementation (Questions)
> ==============
>
> * file format
>
> Although it's tempting to use XML (easy to output, easy to write a
> parser), gstein pointed out that it may create more problems in
> the long run. Storing binary data (and escaping) in XML can be
> painful; scanning for the escape characters can really slow down
> an import; just imagine trying to store an XML file! Even though
> XML may be more convenient at the outset, we'll probably end up
> burning lots of time trying to work around these other issues
> later on.
>
> For this reason, we're thinking some kind of simple binary format.
+1 on binary format, though perhaps the way to go is to use and XML
"table of contents" that points to external files where BLOBS (of
sorts) can be found.
> * should we bother to implement 'diffy' storage of texts in our
> format? My instinct is "no". Dumping and restoring a filesystem
> is a rare operation, so we don't need to be so paranoid about disk
> space usage. It would be extra work to implement diffy-storage,
> and imports would probably be safer (and faster) if we had nothing
> but fulltexts in our dump.
Fulltext. That way anyone who wants to can use (more) easily use the
diffing tool of their choice when examining the dumped data.
> * Reading through our 'libsvn_fs/structure' document, it seems that
> the only data we're not saving in the dump is a node's "Created
> Revision" (CR). It's not clear to me that this is a timeless
> concept. It certainly has no relevance in the new, impending fs
> schema. It seems more like an optimization for our current
> node-id schema. Do others agree?
Scrap it. The information can be derived at restore-time.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Apr 23 23:56:43 2002