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

Re: fsfs revprop packing in f5 Re: Does fsfs revprop packing no longer allow usage of traditional backup software?

From: Stefan Sperling <stsp_at_elego.de>
Date: Wed, 6 Jul 2011 21:40:00 +0200

On Wed, Jul 06, 2011 at 02:30:15PM -0500, Hyrum K Wright wrote:
> After a bit of thinking and discussion, Daniel and I have come up with
> what we think is an acceptable solution, and I'm posting it here for
> validation. (Daniel, please correct me if I've gotten something
> wrong.)
>
> Revision properties will *not* be packed in an sqlite database, but
> will instead be packed in a single packfile, much like revision are to
> today. The key difference is that instead of having a separate
> manifest file, the manifest will be prepended to the packfile, meaning
> the two can be atomically replaced in the case of a propedit.
> This solution has at least of couple of advantages:
> * No need to check a separate "edited" file before reading the packfile
> * The repo maintains consistency in the case of a filesystem copy
> (helpful for backups)
>
> Revprops wouldn't be packed until explicitly asked to do so by
> 'svnadmin pack' which means the frequent post-commit revprop editing
> wouldn't pose a performance problem. In addition, the revprop
> packfile manifest information won't be cached, since the manifest may
> change. We don't anticipate this to be a problem, since it only adds
> an extra seek() to the revprop lookup process (rather than the open()
> + seek() in the rev packing world).
>
> Comments?

Sounds good to me, if this is the last non-trivial change we squeeze
in before release... IIRC this code was initially written within
a couple of days anyway during one of the hackathons in Munich.

I hope we have good regression tests for revprop packing (I haven't
checked)?
Received on 2011-07-06 21:40:50 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.