Eric S. Raymond wrote on Fri, Dec 23, 2011 at 21:12:35 -0500:
> Daniel Shahaf <danielsh_at_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.
Received on 2011-12-24 10:54:01 CET