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

Re: svn 1.8 migration - directory deltification and revprop packing

From: Daniel Shahaf <danielsh_at_elego.de>
Date: Tue, 11 Jun 2013 17:35:38 +0200

C. Michael Pilato wrote on Tue, Jun 11, 2013 at 17:32:59 +0200:
> On 06/11/2013 05:14 PM, Daniel Shahaf wrote:
> > C. Michael Pilato wrote on Tue, Jun 11, 2013 at 14:52:48 +0200:
> >> As for the --deltas option, that has nothing in the world to do with the
> >> types of deltas we're discussing here. (As an aside, I would highly
> >> recommend that, unless you need your dumpfiles to be smaller, avoid the
> >> --deltas option. The performance penalty of using it isn't worth it.)
> >
> > That's because we store skip-deltas but dumpfiles want deltas against
> > predecessor, right?
> >
> > So, two thoughts:
> >
> > - Is this still a problem with the new max-linear-deltification setting?
> >
> > - Can we teach 'svnadmin dump' to just dump whatever delta is stored in
> > the filesystem, plus the base of that delta? For the common case of
> > loading the entire dump file, it's not really important what the delta
> > base is so long as it's older than the dumped revision.
>
> To do so, we'd need to expose the deltas via the libsvn_fs API, which is
> currently not the case. Deltas in the repository filesystem are an
> implementation detail of that filesystem. They are not even guaranteed to
> be implemented in a fashion that is compatible with what is used in the
> repository dump stream format.

I imagined we could have an API similar to
svn_fs_try_process_file_contents(): if you have an svn_txdelta()-delta
precalculated, hand it, else return SVN_ERR_UNSUPPORTED_FEATURE.
Received on 2013-06-11 17:36:16 CEST

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

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