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

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

From: Erik Huelsmann <ehuels_at_gmail.com>
Date: Thu, 30 Jun 2011 23:38:08 +0200

Hi Hyrum,

On Thu, Jun 30, 2011 at 11:33 PM, Hyrum K Wright <hyrum_at_hyrumwright.org>wrote:

> On Thu, Jun 30, 2011 at 3:27 PM, Peter Samuelson <peter_at_p12n.org> wrote:
> >
> > [Ivan Zhakov]
> >> It should be easy to implement editing revprops without using SQLite:
> >> in case someone modify revprop non-packed revprop file is created, in
> >> read operation non-packed revprop file should be considered as more
> >> up-to-date. In next svnadmin pack operation these non-packed files
> >> should be merged back to packed one.
> >
> > +1. This would basically mean there's only _one_ code path for writing
> > revprops, yes? 'svnadmin pack' gets a little more complex, but the
> > rest of libsvn_fs_fs gets simpler.
> >
> > Anyone have time to actually do this? Converting the packed format
> > from sqlite to the same format used for packed revs would be a bonus.
> I like this idea, but it would seem to introduce an additional stat()
> call* for every attempt to fetch a revprop, because you'd first have
> to check the "old" location, and then the packed one. As far as I can
> see, you'd have to do this in every case; in other words, there isn't
> a single-stat() short cut for the common case of non-edited revprops.
> -Hyrum
> * - I don't know why we seem to have this obsession with stat() calls
> around here, but it appears to have rubbed off on me.

Well, we've been able to increase working copy performance throughout the
lifetime of libsvn_wc-1 by working out ways to reduce the number of
apr_stat() calls. I'm not aware there's a huge reason to do that on the
server side though....


Received on 2011-06-30 23:38:41 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.