On Aug 13, 2008, at 15:48, Mark Phippard wrote:
> On Wed, Aug 13, 2008 at 4:47 AM, Alan Barrett <apb_at_cequrux.com> wrote:
>> On Tue, 12 Aug 2008, Paul Koning wrote:
>>> In fsfs, each commit is a single file, but a separate file. That
>>> will
>>> consume disk space according to what your file system has for
>>> allocation granularity. If the clustersize is 4k, a one byte change
>>> will take 4k.
>>
>> In addition, (at least with fsfs), a tiny change to a single file
>> causes the db/revs/${number} file to contain not only a description
>> of the actual change, but also a lot of information about other files
>> in the same directory, even when they haven't changed. In some of my
>> subversion repositories, this apparently useless information takes up
>> the majority of the space.
>
> That information is not useless, it is just part of the tradeoffs for
> making your own custom "database".
True.
I've observed this behavior too. It surprised me at first. It's
particularly noticeable when you change a file in a large directory,
as this forces a new version of that directory (and all its parents).
Each such new version will store all of its entries in the FSFS rev
file (instead of just changes relative to some previous version).
It's an engineering trade-off. Less seeking around to piece together
the full state of the tree, but more space on disk. Not so hot for
large flat trees (like my muse-mode wiki), but on balance I think it
works pretty well.
For more background see ("Bubble-Up Method"):
http://subversion.tigris.org/design.html#server.fs.struct.bubble-up
// Ben
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-08-13 16:48:22 CEST