subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Shahaf <danie...@elego.de>
Subject Re: svn 1.8 migration - directory deltification and revprop packing
Date Tue, 11 Jun 2013 15:35:38 GMT
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.

Mime
View raw message