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

Re: 0.6 draft of dumpfile documentation

From: Eric S. Raymond <esr_at_thyrsus.com>
Date: Fri, 23 Dec 2011 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.

But it doesn't answer my question.

> Next, the answer should be the same for the copyfrom case as it is for
> the svn_fs_path_change_modify case. And it will depend, at least, on
> whether a proplist is present for the node in the dumpfile (no proplist
> => no change) and on whether a Prop-delta: header is present (whether
> the new proplist patches or replaces the preexisting proplist).
>
> That's my understanding, at least.

I'm afraid that doesn't answer my question, either.

-- 
		Eric S. Raymond
Received on 2011-12-24 03:13:13 CET

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