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:[email protected]]
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