[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
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
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
