On Tue, Jul 10, 2012 at 8:09 AM, Trent Nelson <tr...@snakebite.org> wrote:
> Hi Stefan, > > > > This week I had one of my "how hard can it be?" moments > > and finally implemented revprop packing > > Lots of tools, like svnsync, store metadata in r0 rev props. Could this > rev be excluded from packing? > It is excluded already. What's the performance penalty for modifying a packed rev props? From > what you've said, it sounds like packing works by fitting as many rev > props into a 64k chunk, so, let's say I've got a million rev repository. > And the first 1000 revs fit neatly inside the first 64k pack. What > happens when I propedit r1000 and increase its size so that it no longer > neatly fits inside the 64k pack? > That one pack file gets split. I just committed a change that will result in two roughly equally sized pack files after the split - if the revprop sizes allow for it. (Just checking that it won't cause a knock-on re-write effect of all the > other 999,000 packed rev props. Sounds like the manifest map takes care > of avoiding that, but just wanted to make sure.) > > And, heh, this is going to kill Enversion, which currently writes > extensive root metadata to each revision's rev prop as it analyzes a > repository. The I/O will roughly be the same as for 1.7. If you are writing >30k per revision, you will end up with basically the same file structure as before (1 pack file per rev) plus one manifest file per shard. Will there be a way (even if it's at the API level, not CLI) > to disable rev prop packing? > No - unless you can demonstrate that the performance impact is significant. -- Stefan^2. -- Certified & Supported Apache Subversion Downloads: http://www.wandisco.com/subversion/download
