[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: Daniel Shahaf <danielsh_at_elego.de>
Date: Sat, 24 Dec 2011 11:47:28 +0200

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?
> >
> > 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.

More concretely, here is my assumption:

   - No Prop-content-length: => proplist is copied unmodified
   - Else, if Prop-delta: true => proplist patches copysource's or
     (PATH, REV-1)'s proplist
   - Else, proplist replaces any existing proplist

I haven't verified this interpretation. I did verify that an
incremental dump of a revision that modifies the text of a node that
has properties does not print Prop-content-length:.

root@ has replied to your email:
Message-ID: <1324673130.6470.140661015338141_at_webmail.messagingengine.com>
Follow-up on #asfinfra on freenode if you haven't received it.
Received on 2011-12-24 10:48:24 CET

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