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

Re: RFE: pack revprops shards

From: Hyrum K. Wright <hyrum_at_hyrumwright.org>
Date: Fri, 24 Apr 2009 17:22:32 -0500

On Apr 24, 2009, at 3:55 PM, Blair Zajac wrote:

> Hyrum K. Wright wrote:
>> Just playing devil's advocate on this issue. I'm not against it
>> by any means, but have a few questions.
>> On Apr 24, 2009, at 3:11 PM, Blair Zajac wrote:
>>> One could also have the revprops stored as single files if they
>>> are modified
>>> after packing. The lookup code would first try to open the
>>> single revprop file
>>> and if it doesn't exist, then it goes to the packaged file. The
>>> packer could
>>> allow for multiple repackings.
>> In repositories which have a large number of modified-then-packed
>> revprops, this leads to much more storage, and double the I/O.
>> I'm kinda wary of this.
> Not that this is the best solution, but I don't think you can say
> this solution is bad for IO and then claim the sqlite one is a good
> solution. sqlite probably does much more IO than one extra open()
> call that will fail for 95% of the unmodified revprops for this
> solution. I like the sqlite solution, I just don't think it wins on
> IO.

Well, I'd much rather leave the I/O optimization and concurrency
handling to a third-party library, which can arguably worry about
these issues better than we can. It may not be optimal, and it may
not do less I/O than our current solution, but I think it offers a
good trade-off between I/O, space, and other factors.



To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-04-25 00:23:34 CEST

This is an archived mail posted to the Subversion Users mailing list.