On Sun, Aug 17, 2008 at 12:10 PM, Branko Èibej <brane_at_xbc.nu> wrote:
>...
>> gstein_at_tigris.org writes:
>...
>>> +All metadata will be stored into a single SQLite database. This
>>> +includes all of the "entry" fields *and* all of the properties
>>> +attached to the files/directories. SQLite transactions will be used
>>> +rather than the "loggy" mechanics of wc-1.0.
>...
> I'd been wondering about sqlite performance in this context. I have not a
> single data point to anchor my worries to, there's just this nagging guilt
> about the BDB mistake we made.
I do have data points that suggest 100ms per commit. That was on one
particular box, and now that I think about it, it was on an NFS mount.
But if you take a look at some of my other notes, I plan to put
timing/debugging code in there to see what happens. Some algorithms
may need to change to reduce the number of commits, but the main
points is that I'll be keeping an eye on it.
>>> +Base text data will be stored in a multi-level directory structure,
>>> +keyed/named by the MD5 of the file. The database will record
>>> +appropriate mappings, content/compression types, and refcounts for the
>>> +base text files (for the shared case).
>>
>> Sounds sane; we ought to be doing the same in the repository, really
>> (http://subversion.tigris.org/issues/show_bug.cgi?id=2286) :-).
>
> Despite having been a fan of content indexing in the past, these days I
> think a revlog-like structure would be a better idea. I learned a thing or
> two about the goodness of denormalized datastores in the meantime ... not
> that denormalization is always a good thing.
Are you talking revlog on the repository, or for the text-bases on the
client (my original point) ?
For the repository: I agree, and want to work on that post-WC effort.
For the client: I don't understand the benefit... ?
Thanks,
-g
Received on 2008-08-17 22:46:05 CEST