On Dec 14, 1:37 pm, "Eric S. Raymond" <e...@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
