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

Re: svn commit: r32461 - trunk/notes

From: Branko ─îibej <brane_at_xbc.nu>
Date: Sun, 17 Aug 2008 21:10:54 +0200

Karl Fogel wrote:
> gstein_at_tigris.org writes:
>
>> +Basic Storage Mechanics
>> +-----------------------
>> +
>> +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.
>>
>
> Some kind of logginess, or at least carefully ordered actions, will
> still be needed, since we've got working files to deal with. But yeah,
> I think the logginess will get a lot simpler with SQLite transactions.
>

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.

>> +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.

-- Brane

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-08-17 21:11:43 CEST

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.