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.
