You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "Eric S. Raymond" <es...@thyrsus.com> on 2011/12/23 21:20:16 UTC
0.6 draft of dumpfile documentation
I haven't received any notification about an apache.org account. Did I
miss some mail, or are things just slow because of the holidays?
In the 0.5 draft, I asked:
>2. Does a copy operation carry with it properties? In particular,
>if I do a replace on a file without the svn:executable property
>from a source with the svn:executable property, what happens?
I subsequently experimented and found that copy does carry properties.
Here's a case I'm not sure how to check:
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?
Still looking for answers to this:
1. In the Credits section I note that portions of this document are
derived from notes by Ben Collins-Sussman, and mention the people who
have helpfully answered questions. I would also like to credit the
original designers of the format (at least one of whom must have been
Greg Stein) and attach a date to the original design discussion. Can
someone fill me in on the history?
Enclosed is the 0.6 draft. Changes are relatively minor; this thing
is almost done. So is my parser.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
Re: 0.6 draft of dumpfile documentation
Posted by Daniel Shahaf <da...@elego.de>.
Eric S. Raymond wrote on Fri, Dec 23, 2011 at 21:12:35 -0500:
> Daniel Shahaf <da...@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.
Re: 0.6 draft of dumpfile documentation
Posted by Daniel Shahaf <da...@elego.de>.
Eric S. Raymond wrote on Fri, Dec 23, 2011 at 21:12:35 -0500:
> Daniel Shahaf <da...@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: <13...@webmail.messagingengine.com>
Follow-up on #asfinfra on freenode if you haven't received it.
Re: 0.6 draft of dumpfile documentation
Posted by "Eric S. Raymond" <es...@thyrsus.com>.
Daniel Shahaf <da...@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.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
Re: 0.6 draft of dumpfile documentation
Posted by Daniel Shahaf <da...@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.
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.
Re: 0.6 draft of dumpfile documentation
Posted by "Eric S. Raymond" <es...@thyrsus.com>.
Daniel Shahaf <d....@daniel.shahaf.name>:
> If you haven't received it, follow up by mail to root@apache.org.
I have done so.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
Re: 0.6 draft of dumpfile documentation
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
On Fri, Dec 23, 2011, at 15:20, Eric S. Raymond wrote:
> I haven't received any notification about an apache.org account. Did I
> miss some mail, or are things just slow because of the holidays?
You should have received a mail from root@apache.org 72 hours and 22 minutes ago.
If you haven't received it, follow up by mail to root@apache.org.
Re: 0.6 draft of dumpfile documentation
Posted by "Eric S. Raymond" <es...@thyrsus.com>.
Greg Stein <gs...@gmail.com>:
> *shrug* ... the reason people aren't getting around to answering your
> question is because we don't credit individuals like that, anywhere in the
> project. In most cases, we *remove* credits, and just rely on the version
> control history if a need to know ever arises. Otherwise, the various works
> are from the community as a whole.
OK, I will follow that practice.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
Re: 0.6 draft of dumpfile documentation
Posted by Greg Stein <gs...@gmail.com>.
On Dec 23, 2011 3:20 PM, "Eric S. Raymond" <es...@thyrsus.com> wrote:
>...
> Still looking for answers to this:
>
> 1. In the Credits section I note that portions of this document are
> derived from notes by Ben Collins-Sussman, and mention the people who
> have helpfully answered questions. I would also like to credit the
> original designers of the format (at least one of whom must have been
> Greg Stein) and attach a date to the original design discussion. Can
> someone fill me in on the history?
Wasn't me... I never worked on the dumpfile stuff. Maybe Pilato did some of
that.
*shrug* ... the reason people aren't getting around to answering your
question is because we don't credit individuals like that, anywhere in the
project. In most cases, we *remove* credits, and just rely on the version
control history if a need to know ever arises. Otherwise, the various works
are from the community as a whole.
Cheers,
-g
ps. I haven't looked at your update, but yes: this means you'd be credited
in the commit log message rather than in the file.