Peter Samuelson wrote on Wed, Jul 06, 2011 at 15:10:15 -0500: > > [Hyrum K Wright] > > Revprops wouldn't be packed until explicitly asked to do so by > > 'svnadmin pack' which means the frequent post-commit revprop editing > > wouldn't pose a performance problem. > > I still think it'd be possible, even practical, to create packfiles on > the fly, instead of just explicitly via svnadmin pack. This requires
What do you gain by that? > preallocating the 'manifest' region at the top of the file, to > accommodate a full shard. And that in turn is easiest if manifest > entries are fixed-width, say, 16 bytes, space-padded. (This limits us > to 48-bit offsets. At 1000 revs per shard, you can average 256 GB of > revprops per revision. Which is some distance into the realm of the > ridiculous.) > > There is the question of atomicity of updates. But with the HEAD > revision, note that nobody should be trying to read it until the commit > is official! Therefore, assuming you hold a write lock, it should be > perfectly safe to append the revprops to the pack file, then update the > manifest entry, then release the write lock. > > Then we have the possibly common case of editing the HEAD revprops > immediately after commit ... say, from post-commit hook. This can > actually be special-cased, _because_ it is the HEAD rev: > > 0) Definitions: R0 = existing revprops blob, RN = new revprops blob > 1) Rewrite R0 at offset R0 + max(len(R0), len(RN)) > 2) Rewrite R0 manifest entry How do you rewrite the manifest entry atomically? > 3) Write RN at offset R0 > 4) Rewrite RN manifest entry > 5) Truncate file after RN > > This may seem to be a bit of work, but I bet it's not really > noticeable. Plus, post-commit hook performance isn't nearly so > important as performance of the rest of the system. > > Peter
