On Sat, 2006-04-22 at 20:51 -0400, Arlie Davis wrote:
> If you are concerned about entries files that are
> large enough that using an XML DOM is painful, then use one of the streaming
> XML implementations, which give you a great deal of control over how the
> data is read/written, and when.
We were already using a streaming XML implementation.
> Abandoning XML without truly compelling reasons is a very bad idea.
Because...?
> And if
> performance is so critical, then replace the XML entries file with a
> Berkeley DB file (btree), rather than building yet another hacked-up text
> format. At least with BDB, there's already a solid implementation.
So, we're talking about a very small amount of marshalling and
unmarshalling code here. Probably less than we've been using to
interface with the XML library. Text manipulation code is not so scary
that we have to use a monstrously complicated standard format and big
dependency library when there is no interoperability issue.
It's already been pointed out that BDB carries too many restrictions for
use in the wc, and we haven't found its implementation to be
particularly solid for our purposes in the back end. That said, an
efficient way to store many small associations which *did* work over a
remote filesystem, didn't require recovery when a writer process exited
suddenly, didn't change format from version to version of the dependency
library, etc., then that would be interesting. Then we could have
random access to the entries list without doing something grossly
space-inefficient like using an inode per entry.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Apr 23 03:17:55 2006