Re: 0.2 draft of dumpfile documentation

On Dec 14, 1:37 pm, "Eric S. Raymond" <e..._at_thyrsus.com> wrote:

> 1. Is delete on a directory with children expected to succeed or fail?

Succeed. A delete on a directory actually deletes the whole subtree
below it.

> 3. Is add on an existing path expected to fail?

Yes.

> 4. What are the detailed semantics of "change" with copyfrom? I
understand the no-copyfrom case - on a file it's an ordnary text
modification, on a directory a pure property change.

It's an "add-with-history" immediately followed by a modification (of
contents and/or properties)
of the added path.

> Dump decoders should be prepared for the optional lines after
> Node-action to be in any order, except that Content-length is
> always last if it present.
>
> A Node record describes an action on a path relative to the repository
> root, and always begins with the Node-path specification.

No ordering of header lines whatsoever is expected (what the current
implementation
of e.g. "svnadmin dump" does is irrelvant).

> The main reason "replace exists" is because it helps sequential
> processors of the dump stream avoid possibly notifying about multiple
> actions on the same path.

You quote that from Pilato's mail, but in this context it gives the
false impression
that "replace" is an ad-hoc invention for dump files. It's actually
the other way around:

- internally Subversion has only the primitives add, delete, change
and replace
  (and any revision consists of at most one primitive operation for
any path involved)
- the dump file may represent an internal "replace" with either one
"replace" node or
  two nodes: a "delete" followed by a "add"

Note: I just checked Subversion trunk (subversion/libsvn_repos/
dump.c): the code still
does both (delete+add ist used if the add has history, replace
otherwise), but there's
no reason for that except programmer's convenience. Also note that
"svnadmin load"
will correctly load dumps that contain "replace" in this situation.

I think the point of Pilato's remark was this (and this should really
find its way into
the documentation):

For all node records in one revision the Node-paths are unqiue. The
only exception
is a "delete" followed by an "add" on the same Node-path.

Thus a dump consumer can simply store the node records (in one
revision)
as a hash (associative array) with Node-path as the key. The only
excption
is that it must be prepared to "upgrade" a "delete" to a "replace" if
it encounters
an "add" for the same Node-path. Any other combination of actions on
the same
Node-path is a malformed dump.

Cheers, Roderich
Received on 2011-12-15 10:34:16 CET