[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Revprop packing implemented

From: Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com>
Date: Tue, 10 Jul 2012 12:30:03 +0200

On Tue, Jul 10, 2012 at 8:09 AM, Trent Nelson <trent_at_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:
Received on 2012-07-10 12:30:36 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.