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
> 3. Is add on an existing path expected to fail?
> 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
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
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 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
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
For all node records in one revision the Node-paths are unqiue. The
is a "delete" followed by an "add" on the same Node-path.
Thus a dump consumer can simply store the node records (in one
as a hash (associative array) with Node-path as the key. The only
is that it must be prepared to "upgrade" a "delete" to a "replace" if
an "add" for the same Node-path. Any other combination of actions on
Node-path is a malformed dump.
Received on 2011-12-15 10:34:16 CET