Re: revprop packing for fsfs

[Paul Querna]
> Last time this was discussed was in October 2008[3], when hwright had
> packed revprops, but later reverted the work as revprops are mutable
> in r33724.

Is there a reason to try too hard to avoid allocation holes in the
revprops file? Seems to me you could just align each revision to, say,
16 or 32 bytes, and if a propedit operation wants to make it too big to
fit, you move it to the end. Maybe increment a "hole counter" and if
that gets to be too large a fraction of shard size, take a lock and
repack the file.

This would only be problematic if some automated process were to edit a
lot of revprops from comparatively old revisions. (Which I honestly
don't think is a case worth optimizing for.)

> My question for the list: Is the design of using SQLite as the primary
> data storage for revprops acceptable?

A flat file seems preferable, unless there are serious problems with
that which I haven't seen.

-- 
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/