Eric S. Raymond wrote on Fri, Dec 23, 2011 at 21:12:35 -0500: > Daniel Shahaf <danie...@elego.de>: > > Eric S. Raymond wrote on Fri, Dec 23, 2011 at 15:20:16 -0500: > > > 2. In interpreting a Node record which has both a copyfrom source and > > > a property section, it is possible that the copy source node itself > > > has a property section. How are they to be combined? > > > > "The copy source node" is dereferenced into the filesystem, not into the > > dupmfile. (It may not even be in the dumpfile, if -r was used.) > > Therefore, it's relevant not whether a proplist section is present, but > > whether the corresponding node-rev in the filesystem the dump is being > > applied to has properties. > > That is interesting - and it suggests I should add some text about the > behavior of incremental dumps. What you say implies a model in which > when revision N of the dumpfile is being processed, revision N-1 is > already instantiated as state in the filesystem, but the distinction > between what's in the stream and what's in the filesystem is invisible > to the evaluator. Which makes sense.
More concretely: referring to the FS instead of to the dumpfile allows the load process to have a lower memory consumption: it removes the need to make the dumpstream seekable or to cache too much of it in-memory. (Instead, the FS acts as that cache.) That is also why 'svnrdump dump' cannot produce non-deltified dumps.
