Hi Stefan,
Why do you use a default of 64k for a revprop pack? Isn't something like 1MB a more sensible default? I would guess that for the 1000 revisions we usually pack that would fit in a single pack, while with 64K you only can get a few tens/hundreds revisions in a pack, depending on how large the log messages usually are. Does such a small pack size have specific benefits? Bert From: Stefan Fuhrmann [mailto:stefan.fuhrm...@wandisco.com] Sent: vrijdag 6 juli 2012 10:32 To: Subversion Development Subject: Revprop packing implemented Hi devs, This week I had one of my "how hard can it be?" moments and finally implemented revprop packing (did that mainly offline). It passes all tests and seems to work pretty well. It's design deviates from the existing revprop packing branch in that it is more scalable and simpler to implement. Key differences: * Have a configurable limit (default 64k) to the pack file size. Concatenate revprops only up to that limit, but at least one revision's revprops per file. Have the manifest map revs to revprop pack files. IOW, let the OS do all the heavy lifting of storage management. * Make revprop packing a mandatory part of FSFS packing in format 6 repos. There is no need to track revprop packing separately nor to give it a separate format info. Since the new code will not be used unless you create a format 6 repo, I'd like to commit everything directly to /trunk for review instead of creating a new branch or "overwriting" the existing one. This is the order in which I want to commit the changes: * refactor existing code * update the design file * add the revprop pack support * add tests; write more tests * bump the FSFS format Any objections? -- Stefan^2. -- Certified & Supported Apache Subversion Downloads: http://www.wandisco.com/subversion/download