subversion-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From julianf...@apache.org
Subject svn commit: r1606748 [1/2] - in /subversion/branches/move-tracking-2/subversion: include/private/svn_editor3.h libsvn_delta/editor3.c
Date Mon, 30 Jun 2014 14:09:16 GMT
Author: julianfoad
Date: Mon Jun 30 14:09:16 2014
New Revision: 1606748

URL: http://svn.apache.org/r1606748
Log:
On the 'moves-tracking-2' branch: add an experimental new editor design.

* subversion/include/private/svn_editor3.h,
  subversion/libsvn_delta/editor3.c
  New files.

Added:
    subversion/branches/move-tracking-2/subversion/include/private/svn_editor3.h
      - copied, changed from r1606692, subversion/branches/move-tracking-2/subversion/include/private/svn_editor.h
    subversion/branches/move-tracking-2/subversion/libsvn_delta/editor3.c
      - copied, changed from r1606692, subversion/branches/move-tracking-2/subversion/libsvn_delta/editor.c

Copied: subversion/branches/move-tracking-2/subversion/include/private/svn_editor3.h (from r1606692, subversion/branches/move-tracking-2/subversion/include/private/svn_editor.h)
URL: http://svn.apache.org/viewvc/subversion/branches/move-tracking-2/subversion/include/private/svn_editor3.h?p2=subversion/branches/move-tracking-2/subversion/include/private/svn_editor3.h&p1=subversion/branches/move-tracking-2/subversion/include/private/svn_editor.h&r1=1606692&r2=1606748&rev=1606748&view=diff
==============================================================================
--- subversion/branches/move-tracking-2/subversion/include/private/svn_editor.h (original)
+++ subversion/branches/move-tracking-2/subversion/include/private/svn_editor3.h Mon Jun 30 14:09:16 2014
@@ -20,12 +20,16 @@
  * ====================================================================
  * @endcopyright
  *
- * @file svn_editor.h
- * @brief Tree editing functions and structures
+ * @file svn_editor3.h
+ * @brief Tree editing
+ *
+ * @since New in 1.10.
  */
 
-#ifndef SVN_EDITOR_H
-#define SVN_EDITOR_H
+#ifndef SVN_EDITOR3_H
+#define SVN_EDITOR3_H
+
+#include "svn_editor.h"
 
 #include <apr_pools.h>
 
@@ -39,444 +43,697 @@ extern "C" {
 #endif /* __cplusplus */
 
 
-/*** Temporarily private stuff (should move to svn_delta.h when Editor
-     V2 is made public) ***/
+/*
+ * ### Under construction. Currently, two kinds of editor interface are
+ *     declared within the same "svn_editor3_t" framework. This is for
+ *     experimentation, and not intended to stay that way.
+ */
+
+/*
+ * ===================================================================
+ * Possible contexts (uses) for an editor
+ * ===================================================================
+ *
+ * (1) Commit directly to repo
+ *
+ *   - From single-rev to single-rev
+ *   - Diff: with simple context (for simple merge with recent commits)
+ *   - Copies: can send O(1) "copy" (recursive + edits)
+ *   - Copies: can copy from within the new rev (?)
+ *
+ * (2) Commit from WC
+ *
+ *   - From mixed-rev to single-rev
+ *   - Rx needs to be told the "from" revisions
+ *   - Diff: with simple context (for simple merge with recent commits)
+ *   - Copies: can copy from within the new rev (?)
+ *
+ * (3) Update/Switch
+ *
+ *   - One change per *WC* path rather than per *repo* path
+ *   - From mixed-rev to single-rev
+ *   - Rx initially has a complete copy of the "from" state
+ *   - Diff: with context (for merging)
+ *   - Copies: can expand "copy" (non-recursive)
+ *
+ * (4) Diff (wc-base/repo:repo) (for merging/patching/displaying)
+ *
+ *   - From mixed-rev (for wc-base) to single-rev
+ *       (enhancement: mixed-rev "to" state?)
+ *   - Rx needs to be told the "from" revisions
+ *   - Diff: with context (for merging)
+ *   - Diff: can be reversible
+ *   - Copies: can send O(1) "copy" (recursive + edits)
+ *   - Copies: can expand "copy" (non-recursive)
+ *
+ * ===================================================================
+ * Two different styles of "editing"
+ * ===================================================================
+ *
+ * (1) Ordered, cumulative changes to a txn
+ *
+ * (2) Transmission of a set of independent changes
+ *
+ * These can be mixed: e.g. one interface declared here uses style (1)
+ * for tree changes with style (2) for content changes.
+ *
+ * ===================================================================
+ * WC update/switch
+ * ===================================================================
+ *
+ * How Subversion does an update (or switch), roughly:
+ *
+ *   - Client sends a "report" of WC base node locations to server.
+ *   - Server calculates a diff from reported mixed-rev WC-base to
+ *     requested single-rev target.
+ *   - Server maps repo paths to WC paths (using the report) before
+ *     transmitting edits.
+ *
+ * ===================================================================
+ * Commit from WC
+ * ===================================================================
+ * 
+ * How Subversion does a commit, roughly:
+ *
+ *   - Server starts a txn based on current head rev
+ *
+ *                   r1 2 3 4 5 6 7 8 head  txn
+ *     WC-base  @4 -> A . . M . . . . .     |...
+ *      |_B     @3 -> A . M . . . . . .  == |...D
+ *      |_C     @3 -> A . M . . . . . .     |...
+ *        |_foo @6 -> . A . . . M . D .     |...
+ *       \_____________________________________/
+ *            del /B r3
+ *
+ *   - Client sends changes based on its WC-base rev for each node,
+ *     sending "this is the base rev I'm using" for each node.
+ *
+ *   - Server "merges" the client's changes into the txn on the fly,
+ *     rejecting as "out of date" any change that requires a non-trivial
+ *     merge.
+ *
+ *                   r1 2 3 4 5 6 7 8 head
+ *     WC-base  @4 -> A . . M . . . . .
+ *      |_B     @3 -> A . M . . . . . .    txn
+ *      |_C     @3 -> A . M . . . . . . \  |...
+ *        |_foo @6 -> . A . . . M . D .  \ |...x
+ *       \                                 |...
+ *        \                                |...OOD! (deleted since r6)
+ *         \___________________________________/
+ *            edit /C/foo r6
+ *
+ *   - Server "merges" the txn in the same way with any further commits,
+ *     until there are no further commits, and then commits the txn.
+ *
+ * The old design assumes that the client can refer to a node by its path.
+ * Either this path in the txn refers to the same node as in the WC base,
+ * or the WC base node has since been deleted and perhaps replaced. This is
+ * detected by the OOD check. The node's path-in-txn can never be different
+ * from its path-in-WC-base.
+ *
+ * When we introduce moves, it is possible that nodes referenced by the WC
+ * will have been moved in the repository after the WC-base and before the
+ * txn-base. Unless the client queries for such moves, it will not know
+ * what path-in-txn corresponds to each path-in-WC-base.
+ * 
+ * It seems wrong to design an editor interface that requires there have
+ * been no moves in the repository between the WC base and the txn-base
+ * affecting the paths being referenced in the commit. Not totally
+ * unreasonable for the typical work flows of today, but unreasonably
+ * restricting the work flows that should be possible in the future with
+ * move tracking in place.
+ */
+
+/**
+ * @defgroup svn_editor The editor interface
+ * @{
+ */
+
+/** Tree Editor
+ */
+typedef struct svn_editor3_t svn_editor3_t;
 
-/** Callback to retrieve a node's entire set of properties.  This is
- * needed by the various editor shims in order to effect backwards
- * compatibility.
- *
- * Implementations should set @a *props to the hash of properties
- * associated with @a path in @a base_revision, allocating that hash
- * and its contents in @a result_pool, and should use @a scratch_pool
- * for temporary allocations.
+/** A location in the current transaction (when @a rev == -1) or in
+ * a revision (when @a rev != -1). */
+typedef struct pathrev_t
+{
+  svn_revnum_t rev;
+  const char *relpath;
+} pathrev_t;
+
+/** Node-Branch Identifier -- like the FSFS <node-id>.<copy-id>.
+ * (Presently a null-terminated C string.) */
+typedef char *svn_editor3_nbid_t;
+
+/** Versioned content of a node, excluding tree structure information.
+ *
+ * This specifies the content (properties, text of a file, symbolic link
+ * target) directly, or by reference to an existing committed node, or
+ * by a delta against such a reference content.
  *
- * @a baton is an implementation-specific closure.
+ * ### An idea: If the sender and receiver agree, the content for a node
+ *     may be specified as "null" to designate that the content is not
+ *     available. For example, when a client performing a WC update has
+ *     no read authorization for a given path, the server may send null
+ *     content and the client may record an 'absent' WC node. (This
+ *     would not make sense in a commit.)
  */
-typedef svn_error_t *(*svn_delta_fetch_props_func_t)(
-  apr_hash_t **props,
-  void *baton,
-  const char *path,
-  svn_revnum_t base_revision,
-  apr_pool_t *result_pool,
-  apr_pool_t *scratch_pool
-  );
-
-/** Callback to retrieve a node's kind.  This is needed by the various
- * editor shims in order to effect backwards compatibility.
+typedef struct svn_editor3_node_content_t svn_editor3_node_content_t;
+
+/** The kind of the checksum to be used throughout the #svn_editor3_t APIs.
+ */
+#define SVN_EDITOR3_CHECKSUM_KIND svn_checksum_sha1
+
+
+/** These functions are called by the tree delta driver to edit the target.
  *
- * Implementations should set @a *kind to the node kind of @a path in
- * @a base_revision, using @a scratch_pool for temporary allocations.
+ * @see svn_editor3_t.
  *
- * @a baton is an implementation-specific closure.
+ * @defgroup svn_editor3_drive Driving the editor
+ * @{
  */
-typedef svn_error_t *(*svn_delta_fetch_kind_func_t)(
-  svn_node_kind_t *kind,
-  void *baton,
-  const char *path,
-  svn_revnum_t base_revision,
-  apr_pool_t *scratch_pool
-  );
-
-/** Callback to fetch the name of a file to use as a delta base.
- *
- * Implementations should set @a *filename to the name of a file
- * suitable for use as a delta base for @a path in @a base_revision
- * (allocating @a *filename from @a result_pool), or to @c NULL if the
- * base stream is empty.  @a scratch_pool is provided for temporary
- * allocations.
+
+/*
+ * ===================================================================
+ * Editor for Commit from WC, with Incremental Path-Based Tree Changes
+ * ===================================================================
+ *
+ * Versioning model assumed:
+ *
+ *   - per-node, copying-is-branching
+ *   - copying is independent per node: a copy-child is not detectably
+ *     "the same copy" as its parent, it's just copied at the same time
+ *       => (cp ^/a@5 b; del b/c; cp ^/a/c@5 b/c) == (cp ^/a@5 b)
+ *   - a node-rev's versioned state consists of:
+ *        its tree linkage (parent node-branch identity, name)
+ *        its content (props, text, link-target)
+ *   - resurrection is supported
+ *
+ * Edit Operations:
+ *
+ *   - mk  kind               {dir-path | ^/dir-path@rev}[1] new-name[2]
+ *   - cp  ^/from-path@rev[3] {dir-path | ^/dir-path@rev}[1] new-name[2]
+ *   - cp  from-path[4]       {dir-path | ^/dir-path@rev}[1] new-name[2]
+ *   - mv  ^/from-path@rev[4] {dir-path | ^/dir-path@rev}[1] new-name[2]
+ *   - res ^/from-path@rev[3] {dir-path | ^/dir-path@rev}[1] new-name[2]
+ *   - rm                     {path | ^/path@rev}[5]
+ *   - put new-content        {path | ^/path@rev}[5]
+ *
+ * Preconditions:
+ *
+ *   [1] target parent dir must exist in txn
+ *   [2] target name (in parent dir) must not exist in txn
+ *   [3] source must exist in committed revision
+ *   [4] source must exist in txn
+ *   [5] target must exist in txn
+ *
+ * Characteristics of this editor:
+ *
+ *   - tree changes form an ordered list
+ *   - content changes are unordered and independent
+ *   - all tree changes MAY be sent before all content changes
+ *
+ *   ### In order to expand the scope of this editor to situations like
+ *       update/switch, where the receiver doesn't have the repository
+ *       to refer to, Can we add a full-traversal kind of copy?
+ *       Is that merely a matter of driving the same API in a different
+ *       way ("let the copy operation mean non-recursive copy")? Or is
+ *       it totally out of scope? (To support WC update we need other
+ *       changes too, not just this.)
+ *
+ * Description of operations:
+ *
+ *   - "cp", "mv" and "rm" are recursive; "mk" and "put" are non-recursive.
+ *
+ *   - "mk": Create a single new node, not related to any other existing
+ *     node. The default content is empty, and MAY be altered by "put".
+ *
+ *   - "cp": Create a copy of the subtree found at the specified "from"
+ *     location in a committed revision or [if supported] in the current
+ *     txn. Each node in the target subtree is marked as "copied from" the
+ *     node with the corresponding path in the source subtree.
+ *
+ *   - "mv": Move a subtree to a new parent node-branch and/or a new name.
+ *     The source must be present in the txn but is specified by reference
+ *     to a location in a committed revision.
+ *
+ *   - "res": Resurrect a previously deleted node-branch. The specified
+ *     source is any location at which this node-branch existed, not
+ *     necessarily at its youngest revision nor even within its most
+ *     recent period of existence. The default content is that of the
+ *     source location, and MAY be altered by "put".
+ *
+ *     The source node-branch MUST NOT exist in the txn. If the source
+ *     node-branch exists in the txn-base, resurrection would be
+ *     equivalent to reverting a local delete in the txn; the sender
+ *     SHOULD NOT do this. [### Why not? Just because it seems like
+ *     unnecessary flexibility.]
+ *
+ *     ### Can we have a recursive resurrect operation? What should it do
+ *         if a child node is still alive (moved or already resurrected)?
+ *
+ *   - "rm": Remove the specified node and, recursively, all nodes that
+ *     are currently its children in the txn. It does not delete nodes
+ *     that used to be its children that have since been moved away.
+ *     "rm" SHOULD NOT be used on a node-branch created by "mk" nor on the
+ *     root node-branch created by "cp", but MAY be used on a child of a
+ *     copy.
+ *
+ *   - "put": Set the content of a node to the specified value. (The new
+ *     content may be described in terms of a delta against another node's
+ *     content.)
+ *
+ *     "put" MAY be sent for any node that exists in the final state, and
+ *     SHOULD NOT be sent for a node that will no longer exist in the final
+ *     state. "put" SHOULD NOT be sent more than once for any node-branch.
+ *     "put" MUST provide the right kind of content to match the node kind;
+ *     it cannot change the kind of a node nor convert the content to match
+ *     the node kind.
+ *
+ * Commit Rebase:
+ *
+ *   - We assume the rebase will require there be no moves in
+ *     intervening commits that overlap path-wise with the edits we are
+ *     making. (If it would follow such moves while merging "on the fly",
+ *     then it would be harder to design the editor such that the sender
+ *     would know what paths-in-txn to refer to.)
+ *
+ *     This is quite a stringent restriction. See "Paths" below.
+ *
+ * Notes on Paths:
+ *
+ *   - A bare "path" refers to a "path-in-txn", that is a path in the
+ *     current state of the transaction. ^/path@rev refers to a path in a
+ *     committed revision which is to be traced to the current transaction.
+ *     A path-in-txn can refer to a node that was created with "mk" or
+ *     "cp" (including children) and MAY [### or SHOULD NOT?] refer to a
+ *     node-branch that already existed before the edit began.
+ *
+ *   - Ev1 declares, by nesting, exactly what parent dir each operation
+ *     refers to: a pre-existing one (in which case it checks it's still
+ *     the same one) or one it has just created in the txn. We make this
+ *     distinction with {path-in-txn | ^/path-in-rev@rev} instead.
+ *
+ *   - When the target path to "mk" or "cp" or "mv" is specified as
+ *     ^/dir-path@rev, the new (root) path to be created in the txn is:
+ *
+ *         (^/dir-path@rev traced forward to the txn)/(new-name)
+ *
+ *     When the target path to "rm" or "put" is specified as ^/path@rev,
+ *     the path to be removed or changed in the txn is:
+ *
+ *         (^/path@rev traced forward to the txn)
+ *
+ *   - Why use the semantic form "^/path@rev" rather than
+ *     (path-in-txn, wc-base-rev)?
+ * 
+ *     Basically because, in general (if other commits on the server
+ *     are allowed to move the nodes that this commit is editing),
+ *     then (path-in-txn, wc-base-rev) does not unambiguously identify
+ *     a node-revision or a specific path in revision wc-base-rev. The
+ *     sender cannot know what path in the txn corresponds to a given path
+ *     in wc-base-rev.
+ *
+ *     The server needs to identify the specific node-revision on which
+ *     the client is basing a change, in order to check whether it is
+ *     out of date. If the base of the change is out of date, a merge of
+ *     this node would be required. The merge cannot be done on the server
+ *     as then the committed version may differ from the version sent by
+ *     the client, and there is no mechanism to inform the client of this.
+ *     Therefore the commit must be rejected and the merge done on the
+ *     client side via an "update".
+ *
+ *     (As a possible special case, if each side of the merge has identical
+ *     changes, this may be considered a null merge when a "permissive"
+ *     strictness policy is in effect.)
+ * 
+ *     Given "^/path@rev" the receiver can trace the node-branch forward
+ *     from ^/path@rev to the txn, and find the path at which it is
+ *     currently located in the txn (or find that it is not present), as
+ *     well as discovering whether there was any change to it (including
+ *     deletion) between ^/path@rev and the txn-base.
+ * 
+ *     When the node-branch is traced forward to the txn, due to moves in
+ *     the txn the path-in-txn may be different from the initial path.
+ *     The client needs to know the path-in-txn in order for future operations.
+ *     (This is the case even if the out-of-date check rejects any move
+ *     between WC-base and txn-base that affects the node-branch.)
+ *
+ *     Given (path-in-txn, wc-base-rev), if the OOD check *allows* merging
+ *     with repository-side moves, then the sender cannot know what the paths
+ *     in the txn-base are, and so cannot know what path-in-txn identifies
+ *     any node that existed in an earlier revision.
+ *
+ *     Given (path-in-txn, wc-base-rev), if the OOD check *forbids* merging
+ *     with repository-side moves then the receiver can trace backward
+ *     from path-in-txn to path-in-txn-base and then from path-in-txn-base
+ *     to path-in-rev, and find:
+ *
+ *       (a) this node-branch did not exist in "rev" => OOD
+ *       (b) path-in-rev != path-in-txn-base => OOD
+ *       (c) path-in-rev == path-in-txn-base => OOD iff changed
+ *
+ *     It would seem unnecessarily restrictive to expect that we would
+ *     never want the OOD check to allow merging with a repository-side
+ *     move of a parent of the node we are editing.
+ *
+ *   - When a target path is specified by ^/path@rev, note that the sender
+ *     and the receiver both have to map that path forward through moves
+ *     to calculate the corresponding path-in-txn.
+ *
+ *     ### If the server can merge the edits with repository-side moves
+ *     on the fly, then the sender will not know what in-txn paths to
+ *     refer to subsequently.
+ *
+ *     ### One way to support this: the sender could use "^/path@rev" to
+ *     refer to a pre-existing node, appended with any sub-path created in
+ *     the txn:
+ *
+ *         [^/path/in/rev] @rev [/path/components/created/within/txn]
+ *
+ *     The "^/path/in/rev@rev" part acts like an unambiguous node-id for
+ *     each pre-existing node. The remaining part acts like an identifier
+ *     for nodes created in the txn, but is unambiguous only if we take
+ *     care not to allow them to be moved around freely.
+ *
+ * Notes on Copying:
+ *
+ *   - Copy from path-in-txn is required iff we want to support copying
+ *     from "this revision". If we don't then the source is necessarily
+ *     a pre-existing node and so can be referenced by ^/path@rev.
+ *
+ *   - There is no provision for making a non-tracked copy of a subtree,
+ *     nor a copy in which some nodes are tracked and others untracked,
+ *     in a single operation.
+ *
+ * Notes on Moving:
+ *
+ *   - There is no operation to move a subtree whose root node was created
+ *     in this txn, merely because it is not necessary. (A node created by
+ *     "mk" can always be created in the required location. A subtree of a
+ *     copy can be moved by deleting it and making a new copy from the
+ *     corresponding subtree of the original copy root, as there is no
+ *     distinction between the first copy and the second copy.)
  *
- * @a baton is an implementation-specific closure.
  */
-typedef svn_error_t *(*svn_delta_fetch_base_func_t)(
-  const char **filename,
-  void *baton,
-  const char *path,
-  svn_revnum_t base_revision,
-  apr_pool_t *result_pool,
-  apr_pool_t *scratch_pool
-  );
-
-/** Collection of callbacks used for the shim code.  This structure
- * may grow additional fields in the future.  Therefore, always use
- * svn_delta_shim_callbacks_default() to allocate new instances of it.
+
+/** Make a single new node ("versioned object") with empty content.
+ * 
+ * Set the node kind to @a new_kind. Create the node in the parent
+ * directory node-branch specified by @a parent_loc which may be either in
+ * a committed revision or in the current txn. Set the new node's name to
+ * @a new_name.
+ *
+ * The new node is not related by node identity to any other existing node
+ * nor to any other node created by another "mk" operation.
+ *
+ * Preconditions: see above.
+ *
+ * @node "put" is optional for a node made by "mk".
  */
-typedef struct svn_delta_shim_callbacks_t
-{
-  svn_delta_fetch_props_func_t fetch_props_func;
-  svn_delta_fetch_kind_func_t fetch_kind_func;
-  svn_delta_fetch_base_func_t fetch_base_func;
-  void *fetch_baton;
-} svn_delta_shim_callbacks_t;
+svn_error_t *
+svn_editor3_mk(svn_editor3_t *editor,
+               svn_node_kind_t new_kind,
+               pathrev_t parent_loc,
+               const char *new_name);
 
-/** Return a collection of default shim functions in @a result_pool.
+/** Create a copy of a subtree.
+ *
+ * The source subtree is found at @a from_loc. If @a from_loc is a
+ * location in a committed revision, make a copy from (and referring to)
+ * that location. [If supported] If @a from_loc is a location in the
+ * current txn, make a copy from the current txn, which when committed
+ * will refer to the committed revision.
+ *
+ * Create the root node of the new subtree in the parent directory
+ * node-branch specified by @a parent_loc (which may be either in a
+ * committed revision or in the current txn) with the name @a new_name.
+ *
+ * Each node in the target subtree has a "copied from" relationship with
+ * the node with the corresponding path in the source subtree.
+ *
+ * The content of a node copied from an existing revision is, by default,
+ * the content of the source node. The content of a node copied from this
+ * revision is, by default, the FINAL content of the source node as
+ * committed, even if the source node is changed after the copy operation.
+ * In either case, the default content MAY be changed by a "put".
  */
-svn_delta_shim_callbacks_t *
-svn_delta_shim_callbacks_default(apr_pool_t *result_pool);
+svn_error_t *
+svn_editor3_cp(svn_editor3_t *editor,
+               pathrev_t from_loc,
+               pathrev_t parent_loc,
+               const char *new_name);
 
+/** Move a subtree to a new parent directory and/or a new name.
+ *
+ * The root node of the source subtree in the current txn is the node-branch
+ * specified by @a from_loc. @a from_loc must refer to a committed revision.
+ *
+ * Create the root node of the new subtree in the parent directory
+ * node-branch specified by @a parent_loc (which may be either in a
+ * committed revision or in the current txn) with the name @a new_name.
+ *
+ * Each node in the target subtree remains the same node-branch as
+ * the node with the corresponding path in the source subtree.
+ */
+svn_error_t *
+svn_editor3_mv(svn_editor3_t *editor,
+               pathrev_t from_loc,
+               pathrev_t new_parent_loc,
+               const char *new_name);
 
-
-/** Transforming trees ("editing").
+/** Resurrect a node.
+ *
+ * Resurrect the node-branch that previously existed at @a from_loc,
+ * a location in a committed revision. Put the resurrected node at
+ * @a parent_loc, @a new_name.
  *
- * In Subversion, we have a number of occasions where we transform a tree
- * from one state into another. This process is called "editing" a tree.
+ * Set the content to @a new_content.
+ */
+svn_error_t *
+svn_editor3_res(svn_editor3_t *editor,
+                pathrev_t from_loc,
+                pathrev_t parent_loc,
+                const char *new_name);
+
+/** Remove the existing node-branch identified by @a loc and, recursively,
+ * all nodes that are currently its children in the txn.
  *
- * In processing a `commit' command:
- * - The client examines its working copy data to determine the set of
- *   changes necessary to transform its base tree into the desired target.
- * - The client networking library delivers that set of changes/operations
- *   across the wire as an equivalent series of network requests (for
- *   example, to svnserve as an ra_svn protocol stream, or to an
- *   Apache httpd server as WebDAV commands)
- * - The server receives those requests and applies the sequence of
- *   operations on a revision, producing a transaction representing the
- *   desired target.
- * - The Subversion server then commits the transaction to the filesystem.
- *
- * In processing an `update' command, the process is reversed:
- * - The Subversion server module talks to the filesystem and computes a
- *   set of changes necessary to bring the client's working copy up to date.
- * - The server serializes this description of changes, and delivers it to
- *   the client.
- * - The client networking library receives that reply, producing a set
- *   of changes/operations to alter the working copy into the revision
- *   requested by the update command.
- * - The working copy library applies those operations to the working copy
- *   to align it with the requested update target.
- *
- * The series of changes (or operations) necessary to transform a tree from
- * one state into another is passed between subsystems using this "editor"
- * interface. The "receiver" edits its tree according to the operations
- * described by the "driver".
- *
- * Note that the driver must have a perfect understanding of the tree which
- * the receiver will be applying edits upon. There is no room for error here,
- * and the interface embodies assumptions/requirements that the driver has
- * about the targeted tree. As a result, this interface is a standardized
- * mechanism of *describing* those change operations, but the intimate
- * knowledge between the driver and the receiver implies some level of
- * coupling between those subsystems.
- *
- * The set of changes, and the data necessary to describe it entirely, is
- * completely unbounded. An addition of one simple 20 GB file might be well
- * past the available memory of a machine processing these operations.
- * As a result, the API to describe the changes is designed to be applied
- * in a sequential (and relatively random-access) model. The operations
- * can be streamed from the driver to the receiver, resulting in the
- * receiver editing its tree to the target state defined by the driver.
- *
- *
- * <h3>History</h3>
- *
- * Classically, Subversion had a notion of a "tree delta" which could be
- * passed around as an independent entity. Theory implied this delta was an
- * entity in its own right, to be used when and where necessary.
- * Unfortunately, this theory did not work well in practice. The producer
- * and consumer of these tree deltas were (and are) tightly coupled. As noted
- * above, the tree delta producer needed to be *totally* aware of the tree
- * that it needed to edit. So rather than telling the delta consumer how to
- * edit its tree, the classic #svn_delta_editor_t interface focused
- * entirely on the tree delta, an intermediate (logical) data structure
- * which was unusable outside of the particular, coupled pairing of producer
- * and consumer. This generation of the API forgoes the logical tree delta
- * entity and directly passes the necessary edits/changes/operations from
- * the producer to the consumer. In our new parlance, one subsystem "drives"
- * a set of operations describing the change, and a "receiver" accepts and
- * applies them to its tree.
- *
- * The classic interface was named #svn_delta_editor_t and was described
- * idiomatically as the "editor interface". This generation of the interface
- * retains the "editor" name for that reason. All notions of a "tree delta"
- * structure are no longer part of this interface.
- *
- * The old interface was purely vtable-based and used a number of special
- * editors which could be interposed between the driver and receiver. Those
- * editors provided cancellation, debugging, and other various operations.
- * While the "interposition" pattern is still possible with this interface,
- * the most common functionality (cancellation and debugging) have been
- * integrated directly into this new editor system.
- *
- *
- * <h3>Implementation Plan</h3>
- * @note This section can be removed after Ev2 is fully implemented.
- *
- * The delta editor is pretty engrained throughout Subversion, so attempting
- * to replace it in situ is somewhat akin to performing open heart surgery
- * while the patient is running a marathon.  However, a viable plan should
- * make things a bit easier, and help parallelize the work.
- *
- * In short, the following items need to be done:
- *  -# Implement backward compatibility wrappers ("shims")
- *  -# Use shims to update editor consumers to Ev2
- *  -# Update editor producers to drive Ev2
- *     - This will largely involve rewriting the RA layers to accept and
- *       send Ev2 commands
- *  -# Optimize consumers and producers to leverage the features of Ev2
- *
- * The shims are largely self-contained, and as of this writing, are almost
- * complete.  They can be released without much ado.  However, they do add
- * <em>significant</em> performance regressions, which make releasing code
- * which is half-delta-editor and half-Ev2 inadvisable.  As such, the updating
- * of producers and consumers to Ev2 will probably need to wait until 1.9,
- * though it could be largely parallelized.
+ * It does not delete nodes that used to be children of the specified
+ * node-branch that have since been moved away.
+ */
+svn_error_t *
+svn_editor3_rm(svn_editor3_t *editor,
+               pathrev_t loc);
+
+/** Set the content of the node-branch identified by @a loc.
  *
+ * Set the content to @a new_content.
+ */
+svn_error_t *
+svn_editor3_put(svn_editor3_t *editor,
+                pathrev_t loc,
+                const svn_editor3_node_content_t *new_content);
+
+
+/*
+ * ========================================================================
+ * Editor for Commit from WC, with Separate Unordered Per-Node Tree Changes
+ * ========================================================================
  *
- * @defgroup svn_editor The editor interface
- * @{
+ * Versioning model assumed:
+ *
+ *   - per-node, copying-is-branching
+ *   - copying is independent per node: a copy-child is not detectably
+ *     "the same copy" as its parent, it's just copied at the same time
+ *       => (cp ^/a@5 b; del b/c; cp ^/a/c@5 b/c) == (cp ^/a@5 b)
+ *   - a node-rev's versioned state consists of:
+ *        its tree linkage (parent node-branch identity, name)
+ *        its content (props, text, link-target)
+ *   - resurrection is supported
+ *
+ * Edit Operations:
+ *
+ *   - add     kind      new-parent-nb[2] new-name new-content  ->  new-nb
+ *   - copy    nb@rev[3] new-parent-nb[2] new-name new-content  ->  new-nb
+ *   - delete  nb[1]   since-rev
+ *   - alter   nb[1,2] since-rev new-parent-nb[2] new-name new-content
+ *
+ * Preconditions:
+ *
+ *   [1] node-branch must exist in initial state
+ *   [2] node-branch must exist in final state
+ *   [3] source must exist in committed revision or txn final state
+ *
+ * Characteristics of this editor:
+ *
+ *   - tree changes and content changes are specified per node
+ *   - the changes for each node are unordered and mostly independent;
+ *     the only dependencies are those needed to ensure the result is a
+ *     directory hierarchy
+ *   - copies are non-recursive
+ *     ### Can we design recursive (cheap) copy?
+ *
+ *
+ * Notes on Copying:
+ *
+ *   - copy_one and copy_tree are separate. In this model it doesn't
+ *     make sense to describe a copy-and-modify by means of generating
+ *     a full copy (with ids, at least implicitly, for each node) and
+ *     then potentially "deleting" some of the generated child nodes.
+ *     Instead, each node has to be specified in its final state or not
+ *     at all. Tree-copy therefore generates an immutable copy, while
+ *     single-node copy supports arbitrary copy-and-modify operations,
+ *     and tree-copy can be used for any unmodified subtrees therein.
+ *     There is no need to reference the root node of a tree-copy again
+ *     within the same edit, and so no id is provided.
  */
 
-/** An abstract object that edits a target tree.
+/** Create a new versioned object of kind @a new_kind.
+ * 
+ * Assign the new node a locally unique node-branch-id, @a local_nbid,
+ * with which it can be referenced within this edit.
+ *
+ * Set the node's parent and name to @a new_parent_nbid and @a new_name.
  *
- * @note The term "follow" means at any later time in the editor drive.
- * Terms such as "must", "must not", "required", "shall", "shall not",
- * "should", "should not", "recommended", "may", and "optional" in this
- * document are to be interpreted as described in RFC 2119.
- *
- * @note The editor objects are *not* reentrant. The receiver should not
- * directly or indirectly invoke an editor API with the same object unless
- * it has been marked as explicitly supporting reentrancy during a
- * receiver's callback. This limitation extends to the cancellation
- * callback, too. (This limitation is due to the scratch_pool shared by
- * all callbacks, and cleared after each callback; a reentrant call could
- * clear the outer call's pool). Note that the code itself is reentrant, so
- * there is no problem using the APIs on different editor objects.
- *
- * \n
- * <h3>Life-Cycle</h3>
- *
- * - @b Create: A receiver uses svn_editor_create() to create an
- *    "empty" svn_editor_t.  It cannot be used yet, since it still lacks
- *    actual callback functions.  svn_editor_create() sets the
- *    #svn_editor_t's callback baton and scratch pool that the callback
- *    functions receive, as well as a cancellation callback and baton
- *    (see "Cancellation" below).
- *
- * - @b Set callbacks: The receiver calls svn_editor_setcb_many() or a
- *    succession of the other svn_editor_setcb_*() functions to tell
- *    #svn_editor_t which functions to call when driven by the various
- *    operations.  Callback functions are implemented by the receiver and must
- *    adhere to the @c svn_editor_cb_*_t function types as expected by the
- *    svn_editor_setcb_*() functions. See: \n
- *      svn_editor_cb_many_t \n
- *      svn_editor_setcb_many() \n
- *      or \n
- *      svn_editor_setcb_add_directory() \n
- *      svn_editor_setcb_add_file() \n
- *      svn_editor_setcb_add_symlink() \n
- *      svn_editor_setcb_add_absent() \n
- *      svn_editor_setcb_alter_directory() \n
- *      svn_editor_setcb_alter_file() \n
- *      svn_editor_setcb_alter_symlink() \n
- *      svn_editor_setcb_delete() \n
- *      svn_editor_setcb_copy() \n
- *      svn_editor_setcb_move() \n
- *      svn_editor_setcb_complete() \n
- *      svn_editor_setcb_abort()
- *
- * - @b Drive: The driver is provided with the completed #svn_editor_t
- *    instance. (It is typically passed to a generic driving
- *    API, which could receive the driving editor calls over the network
- *    by providing a proxy #svn_editor_t on the remote side.)
- *    The driver invokes the #svn_editor_t instance's callback functions
- *    according to the restrictions defined below, in order to describe the
- *    entire set of operations necessary to transform the receiver's tree
- *    into the desired target. The callbacks can be invoked using the
- *    svn_editor_*() functions, i.e.: \n
- *      svn_editor_add_directory() \n
- *      svn_editor_add_file() \n
- *      svn_editor_add_symlink() \n
- *      svn_editor_add_absent() \n
- *      svn_editor_alter_directory() \n
- *      svn_editor_alter_file() \n
- *      svn_editor_alter_symlink() \n
- *      svn_editor_delete() \n
- *      svn_editor_copy() \n
- *      svn_editor_move() \n
- *    \n\n
- *    Just before each callback invocation is carried out, the @a cancel_func
- *    that was passed to svn_editor_create() is invoked to poll any
- *    external reasons to cancel the sequence of operations.  Unless it
- *    overrides the cancellation (denoted by #SVN_ERR_CANCELLED), the driver
- *    aborts the transmission by invoking the svn_editor_abort() callback.
- *    Exceptions to this are calls to svn_editor_complete() and
- *    svn_editor_abort(), which cannot be canceled externally.
- *
- * - @b Receive: While the driver invokes operations upon the editor, the
- *    receiver finds its callback functions called with the information
- *    to operate on its tree. Each actual callback function receives those
- *    arguments that the driver passed to the "driving" functions, plus these:
- *    -  @a baton: This is the @a editor_baton pointer originally passed to
- *       svn_editor_create().  It may be freely used by the callback
- *       implementation to store information across all callbacks.
- *    -  @a scratch_pool: This temporary pool is cleared directly after
- *       each callback returns.  See "Pool Usage".
- *    \n\n
- *    If the receiver encounters an error within a callback, it returns an
- *    #svn_error_t*. The driver receives this and aborts transmission.
- *
- * - @b Complete/Abort: The driver will end transmission by calling \n
- *    svn_editor_complete() if successful, or \n
- *    svn_editor_abort() if an error or cancellation occurred.
- * \n\n
- *
- * <h3>Driving Order Restrictions</h3>
- * In order to reduce complexity of callback receivers, the editor callbacks
- * must be driven in adherence to these rules:
- *
- * - If any path is added (with add_*) or deleted/moved, then
- *   an svn_editor_alter_directory() call must be made for its parent
- *   directory with the target/eventual set of children.
- *
- * - svn_editor_add_directory() -- Another svn_editor_add_*() call must
- *   follow for each child mentioned in the @a children argument of any
- *   svn_editor_add_directory() call.
- *
- * - For each node created with add_*, if its parent was created using
- *   svn_editor_add_directory(), then the new child node MUST have been
- *   mentioned in the @a children parameter of the parent's creation.
- *   This allows the parent directory to properly mark the child as
- *   "incomplete" until the child's add_* call arrives.
- *
- * - A path should never be referenced more than once by the add_*, alter_*,
- *   and delete operations (the "Once Rule"). The source path of a copy (and
- *   its children, if a directory) may be copied many times, and are
- *   otherwise subject to the Once Rule. The destination path of a copy
- *   or move may have alter_* operations applied, but not add_* or delete.
- *   If the destination path of a copy or move is a directory,
- *   then its children are subject to the Once Rule. The source path of
- *   a move (and its child paths) may be referenced in add_*, or as the
- *   destination of a copy (where these new or copied nodes are subject
- *   to the Once Rule).
- *
- * - The ancestor of an added, copied-here, moved-here, or
- *   modified node may not be deleted. The ancestor may not be moved
- *   (instead: perform the move, *then* the edits).
- *
- * - svn_editor_delete() must not be used to replace a path -- i.e.
- *   svn_editor_delete() must not be followed by an svn_editor_add_*() on
- *   the same path, nor by an svn_editor_copy() or svn_editor_move() with
- *   the same path as the copy/move target.
- *
- *   Instead of a prior delete call, the add/copy/move callbacks should be
- *   called with the @a replaces_rev argument set to the revision number of
- *   the node at this path that is being replaced.  Note that the path and
- *   revision number are the key to finding any other information about the
- *   replaced node, like node kind, etc.
- *   @todo say which function(s) to use.
- *
- * - svn_editor_delete() must not be used to move a path -- i.e.
- *   svn_editor_delete() must not delete the source path of a previous
- *   svn_editor_copy() call. Instead, svn_editor_move() must be used.
- *   Note: if the desired semantics is one (or more) copies, followed
- *   by a delete... that is fine. It is simply that svn_editor_move()
- *   should be used to describe a semantic move.
- *
- * - One of svn_editor_complete() or svn_editor_abort() must be called
- *   exactly once, which must be the final call the driver invokes.
- *   Invoking svn_editor_complete() must imply that the set of changes has
- *   been transmitted completely and without errors, and invoking
- *   svn_editor_abort() must imply that the transformation was not completed
- *   successfully.
- *
- * - If any callback invocation (besides svn_editor_complete()) returns
- *   with an error, the driver must invoke svn_editor_abort() and stop
- *   transmitting operations.
- * \n\n
- *
- * <h3>Receiving Restrictions</h3>
- *
- * All callbacks must complete their handling of a path before they return.
- * Since future callbacks will never reference this path again (due to the
- * Once Rule), the changes can and should be completed.
- *
- * This restriction is not recursive -- a directory's children may remain
- * incomplete until later callback calls are received.
- *
- * For example, an svn_editor_add_directory() call during an 'update'
- * operation will create the directory itself, including its properties,
- * and will complete any client notification for the directory itself.
- * The immediate children of the added directory, given in @a children,
- * will be recorded in the WC as 'incomplete' and will be completed in the
- * course of the same operation sequence, when the corresponding callbacks
- * for these items are invoked.
- * \n\n
- *
- * <h3>Timing and State</h3>
- * The calls made by the driver to alter the state in the receiver are
- * based on the receiver's *current* state, which includes all prior changes
- * made during the edit.
- *
- * Example: copy A to B; set-props on A; copy A to C. The props on C
- * should reflect the updated properties of A.
- *
- * Example: mv A@N to B; mv C@M to A. The second move cannot be marked as
- * a "replacing" move since it is not replacing A. The node at A was moved
- * away. The second operation is simply moving C to the now-empty path
- * known as A.
- *
- * <h3>Paths</h3>
- * Each driver/receiver implementation of this editor interface must
- * establish the expected root for all the paths sent and received via
- * the callbacks' @a relpath arguments.
- *
- * For example, during an "update", the driver is the repository, as a
- * whole. The receiver may have just a portion of that repository. Here,
- * the receiver could tell the driver which repository URL the working
- * copy refers to, and thus the driver could send @a relpath arguments
- * that are relative to the receiver's working copy.
- *
- * @note Because the source of a copy may be located *anywhere* in the
- * repository, editor drives should typically use the repository root
- * as the negotiated root. This allows the @a src_relpath argument in
- * svn_editor_copy() to specify any possible source.
- * \n\n
- *
- * <h3>Pool Usage</h3>
- * The @a result_pool passed to svn_editor_create() is used to allocate
- * the #svn_editor_t instance, and thus it must not be cleared before the
- * driver has finished driving the editor.
- *
- * The @a scratch_pool passed to each callback invocation is derived from
- * the @a result_pool that was passed to svn_editor_create(). It is
- * cleared directly after each single callback invocation.
- * To allocate memory with a longer lifetime from within a callback
- * function, you may use your own pool kept in the @a editor_baton.
- *
- * The @a scratch_pool passed to svn_editor_create() may be used to help
- * during construction of the #svn_editor_t instance, but it is assumed to
- * live only until svn_editor_create() returns.
- * \n\n
- *
- * <h3>Cancellation</h3>
- * To allow graceful interruption by external events (like a user abort),
- * svn_editor_create() can be passed an #svn_cancel_func_t that is
- * polled every time the driver invokes a callback, just before the
- * actual editor callback implementation is invoked.  If this function
- * decides to return with an error, the driver will receive this error
- * as if the callback function had returned it, i.e. as the result from
- * calling any of the driving functions (e.g. svn_editor_add_directory()).
- * As with any other error, the driver must then invoke svn_editor_abort()
- * and abort the transformation sequence. See #svn_cancel_func_t.
- *
- * The @a cancel_baton argument to svn_editor_create() is passed
- * unchanged to each poll of @a cancel_func.
- *
- * The cancellation function and baton are typically provided by the client
- * context.
- *
- *
- * @todo ### TODO anything missing?
- *
- * @since New in 1.8.
+ * Set the content to @a new_content.
+ *
+ * For all restrictions on driving the editor, see #svn_editor3_t.
  */
-typedef struct svn_editor_t svn_editor_t;
+svn_error_t *
+svn_editor3_add(svn_editor3_t *editor,
+                svn_editor3_nbid_t local_nbid,
+                svn_node_kind_t new_kind,
+                svn_editor3_nbid_t new_parent_nbid,
+                const char *new_name,
+                const svn_editor3_node_content_t *new_content);
 
-/** The kind of the checksum to be used throughout the #svn_editor_t APIs.
+/** Create a copy of an existing or new node, and optionally change its
+ * content.
+ *
+ * Assign the target node a locally unique node-branch-id, @a local_nbid,
+ * with which it can be referenced within this edit.
+ *
+ * Copy from the source node at @a src_revision, @a src_nbid. If
+ * @a src_revision is #SVN_INVALID_REVNUM, it means copy from within
+ * the new revision being described.
+ *   ### See note on copy_tree().
+ *
+ * Set the target node's parent and name to @a new_parent_nbid and
+ * @a new_name. Set the target node's content to @a new_content.
+ *
+ * @note This copy is not recursive. Children may be copied separately if
+ * required.
  *
- * @note ### This may change before Ev2 is official released, so just like
- * everything else in this file, please don't rely upon it until then.
+ * @see svn_editor3_copy_tree()
+ *
+ * For all restrictions on driving the editor, see #svn_editor3_t.
+ */
+svn_error_t *
+svn_editor3_copy_one(svn_editor3_t *editor,
+                     svn_editor3_nbid_t local_nbid,
+                     svn_revnum_t src_revision,
+                     svn_editor3_nbid_t src_nbid,
+                     svn_editor3_nbid_t new_parent_nbid,
+                     const char *new_name,
+                     const svn_editor3_node_content_t *new_content);
+
+/** Create a copy of an existing or new subtree. Each node in the source
+ * subtree will be copied (branched) to the same relative path within the
+ * target subtree. The nodes created by this copy cannot be modified or
+ * addressed within this edit.
+ *
+ * Set the target root node's parent and name to @a new_parent_nbid and
+ * @a new_name.
+ *
+ * Copy from the source node at @a src_revision, @a src_nbid. If
+ * @a src_revision is #SVN_INVALID_REVNUM, it means copy from within
+ * the new revision being described. In this case the subtree copied is
+ * the FINAL subtree as committed, regardless of the order in which the
+ * edit operations are described.
+ *   ### Is it necessarily the case that the state at the end of the edit
+ *       is the state to be committed (subject to rebasing), or is it
+ *       possible that a later edit might be performed on the txn?
+ *       And how might we apply this principle to a non-commit editor
+ *       such as a WC update?
+ *
+ * The content of each node copied from an existing revision is the content
+ * of the source node. The content of each node copied from this revision
+ * is the FINAL content of the source node as committed.
+ *
+ * @see svn_editor3_copy_one()
+ *
+ * For all restrictions on driving the editor, see #svn_editor3_t.
  */
-#define SVN_EDITOR_CHECKSUM_KIND svn_checksum_sha1
+svn_error_t *
+svn_editor3_copy_tree(svn_editor3_t *editor,
+                      svn_revnum_t src_revision,
+                      svn_editor3_nbid_t src_nbid,
+                      svn_editor3_nbid_t new_parent_nbid,
+                      const char *new_name);
+
+/** Delete the existing node-branch identified by @a nbid.
+ *
+ * @a since_rev specifies the base revision on which this deletion was
+ * performed: the server can consider the change "out of date" if a commit
+ * since then has changed or deleted this node-branch.
+ *
+ * ###  @note The delete is not recursive. Child nodes must be explicitly
+ *      deleted or moved away.
+ *   OR @note The delete is implicitly recursive: each child node that
+ *      is not otherwise moved to a new parent will be deleted as well.
+ *
+ * For all restrictions on driving the editor, see #svn_editor3_t.
+ */
+svn_error_t *
+svn_editor3_delete(svn_editor3_t *editor,
+                   svn_revnum_t since_rev,
+                   svn_editor3_nbid_t nbid);
+
+/** Alter the tree position and/or contents of the node-branch identified
+ * by @a nbid, or resurrect it if it previously existed.
+ *
+ * @a since_rev specifies the base revision on which this edit was
+ * performed: the server can consider the change "out of date" if a commit
+ * since then has changed or deleted this node-branch.
+ *
+ * Set the node's parent and name to @a new_parent_nbid and @a new_name.
+ *
+ * Set the content to @a new_content.
+ *
+ * A no-op change MUST be accepted but, in the interest of efficiency,
+ * SHOULD NOT be sent.
+ *
+ * For all restrictions on driving the editor, see #svn_editor3_t.
+ */
+svn_error_t *
+svn_editor3_alter(svn_editor3_t *editor,
+                  svn_revnum_t since_rev,
+                  svn_editor3_nbid_t nbid,
+                  svn_editor3_nbid_t new_parent_nbid,
+                  const char *new_name,
+                  const svn_editor3_node_content_t *new_content);
+
+/** Drive @a editor's #svn_editor3_cb_complete_t callback.
+ *
+ * Send word that the edit has been completed successfully.
+ *
+ * For all restrictions on driving the editor, see #svn_editor3_t.
+ */
+svn_error_t *
+svn_editor3_complete(svn_editor3_t *editor);
+
+/** Drive @a editor's #svn_editor3_cb_abort_t callback.
+ *
+ * Notify that the edit transmission was not successful.
+ * ### TODO @todo Shouldn't we add a reason-for-aborting argument?
+ *
+ * For all restrictions on driving the editor, see #svn_editor3_t.
+ */
+svn_error_t *
+svn_editor3_abort(svn_editor3_t *editor);
+
+/** @} */
 
 
 /** These function types define the callback functions a tree delta consumer
@@ -486,143 +743,135 @@ typedef struct svn_editor_t svn_editor_t
  * which has the same arguments with these differences:
  *
  * - These "receiving" functions have a @a baton argument, which is the
- *   @a editor_baton originally passed to svn_editor_create(), as well as
+ *   @a editor_baton originally passed to svn_editor3_create(), as well as
  *   a @a scratch_pool argument.
  *
- * - The "driving" functions have an #svn_editor_t* argument, in order to
+ * - The "driving" functions have an #svn_editor3_t* argument, in order to
  *   call the implementations of the function types defined here that are
- *   registered with the given #svn_editor_t instance.
+ *   registered with the given #svn_editor3_t instance.
  *
  * Note that any remaining arguments for these function types are explained
  * in the comment for the "driving" functions. Each function type links to
  * its corresponding "driver".
  *
- * @see svn_editor_t, svn_editor_cb_many_t.
+ * @see svn_editor3_t, svn_editor3_cb_funcs_t.
  *
  * @defgroup svn_editor_callbacks Editor callback definitions
  * @{
  */
 
-/** @see svn_editor_add_directory(), svn_editor_t.
- * @since New in 1.8.
+/** @see svn_editor3_mk(), svn_editor3_t.
  */
-typedef svn_error_t *(*svn_editor_cb_add_directory_t)(
+typedef svn_error_t *(*svn_editor3_cb_mk_t)(
   void *baton,
-  const char *relpath,
-  const apr_array_header_t *children,
-  apr_hash_t *props,
-  svn_revnum_t replaces_rev,
+  svn_node_kind_t new_kind,
+  pathrev_t parent_loc,
+  const char *new_name,
   apr_pool_t *scratch_pool);
 
-/** @see svn_editor_add_file(), svn_editor_t.
- * @since New in 1.8.
+/** @see svn_editor3_cp(), svn_editor3_t.
  */
-typedef svn_error_t *(*svn_editor_cb_add_file_t)(
+typedef svn_error_t *(*svn_editor3_cb_cp_t)(
   void *baton,
-  const char *relpath,
-  const svn_checksum_t *checksum,
-  svn_stream_t *contents,
-  apr_hash_t *props,
-  svn_revnum_t replaces_rev,
+  pathrev_t from_loc,
+  pathrev_t parent_loc,
+  const char *new_name,
   apr_pool_t *scratch_pool);
 
-/** @see svn_editor_add_symlink(), svn_editor_t.
- * @since New in 1.8.
+/** @see svn_editor3_mv(), svn_editor3_t.
  */
-typedef svn_error_t *(*svn_editor_cb_add_symlink_t)(
+typedef svn_error_t *(*svn_editor3_cb_mv_t)(
   void *baton,
-  const char *relpath,
-  const char *target,
-  apr_hash_t *props,
-  svn_revnum_t replaces_rev,
+  pathrev_t from_loc,
+  pathrev_t new_parent_loc,
+  const char *new_name,
   apr_pool_t *scratch_pool);
 
-/** @see svn_editor_add_absent(), svn_editor_t.
- * @since New in 1.8.
+/** @see svn_editor3_res(), svn_editor3_t.
  */
-typedef svn_error_t *(*svn_editor_cb_add_absent_t)(
+typedef svn_error_t *(*svn_editor3_cb_res_t)(
   void *baton,
-  const char *relpath,
-  svn_node_kind_t kind,
-  svn_revnum_t replaces_rev,
+  pathrev_t from_loc,
+  pathrev_t parent_loc,
+  const char *new_name,
   apr_pool_t *scratch_pool);
 
-/** @see svn_editor_alter_directory(), svn_editor_t.
- * @since New in 1.8.
+/** @see svn_editor3_rm(), svn_editor3_t.
  */
-typedef svn_error_t *(*svn_editor_cb_alter_directory_t)(
+typedef svn_error_t *(*svn_editor3_cb_rm_t)(
   void *baton,
-  const char *relpath,
-  svn_revnum_t revision,
-  const apr_array_header_t *children,
-  apr_hash_t *props,
+  pathrev_t loc,
   apr_pool_t *scratch_pool);
 
-/** @see svn_editor_alter_file(), svn_editor_t.
- * @since New in 1.8.
+/** @see svn_editor3_put(), svn_editor3_t.
  */
-typedef svn_error_t *(*svn_editor_cb_alter_file_t)(
+typedef svn_error_t *(*svn_editor3_cb_put_t)(
   void *baton,
-  const char *relpath,
-  svn_revnum_t revision,
-  const svn_checksum_t *checksum,
-  svn_stream_t *contents,
-  apr_hash_t *props,
+  pathrev_t loc,
+  const svn_editor3_node_content_t *new_content,
   apr_pool_t *scratch_pool);
 
-/** @see svn_editor_alter_symlink(), svn_editor_t.
- * @since New in 1.8.
+/** @see svn_editor3_add(), svn_editor3_t.
  */
-typedef svn_error_t *(*svn_editor_cb_alter_symlink_t)(
+typedef svn_error_t *(*svn_editor3_cb_add_t)(
   void *baton,
-  const char *relpath,
-  svn_revnum_t revision,
-  const char *target,
-  apr_hash_t *props,
+  svn_editor3_nbid_t local_nbid,
+  svn_node_kind_t new_kind,
+  svn_editor3_nbid_t new_parent_nbid,
+  const char *new_name,
+  const svn_editor3_node_content_t *new_content,
   apr_pool_t *scratch_pool);
 
-/** @see svn_editor_delete(), svn_editor_t.
- * @since New in 1.8.
+/** @see svn_editor3_copy(), svn_editor3_t.
  */
-typedef svn_error_t *(*svn_editor_cb_delete_t)(
+typedef svn_error_t *(*svn_editor3_cb_copy_one_t)(
   void *baton,
-  const char *relpath,
-  svn_revnum_t revision,
+  svn_editor3_nbid_t local_nbid,
+  svn_revnum_t src_revision,
+  svn_editor3_nbid_t src_nbid,
+  svn_editor3_nbid_t new_parent_nbid,
+  const char *new_name,
+  const svn_editor3_node_content_t *new_content,
   apr_pool_t *scratch_pool);
 
-/** @see svn_editor_copy(), svn_editor_t.
- * @since New in 1.8.
+/** @see svn_editor3_copy(), svn_editor3_t.
  */
-typedef svn_error_t *(*svn_editor_cb_copy_t)(
+typedef svn_error_t *(*svn_editor3_cb_copy_tree_t)(
   void *baton,
-  const char *src_relpath,
   svn_revnum_t src_revision,
-  const char *dst_relpath,
-  svn_revnum_t replaces_rev,
+  svn_editor3_nbid_t src_nbid,
+  svn_editor3_nbid_t new_parent_nbid,
+  const char *new_name,
   apr_pool_t *scratch_pool);
 
-/** @see svn_editor_move(), svn_editor_t.
- * @since New in 1.8.
+/** @see svn_editor3_delete(), svn_editor3_t.
  */
-typedef svn_error_t *(*svn_editor_cb_move_t)(
+typedef svn_error_t *(*svn_editor3_cb_delete_t)(
   void *baton,
-  const char *src_relpath,
-  svn_revnum_t src_revision,
-  const char *dst_relpath,
-  svn_revnum_t replaces_rev,
+  svn_revnum_t since_rev,
+  svn_editor3_nbid_t nbid,
   apr_pool_t *scratch_pool);
 
-/** @see svn_editor_complete(), svn_editor_t.
- * @since New in 1.8.
+/** @see svn_editor3_alter(), svn_editor3_t.
  */
-typedef svn_error_t *(*svn_editor_cb_complete_t)(
+typedef svn_error_t *(*svn_editor3_cb_alter_t)(
   void *baton,
+  svn_revnum_t since_rev,
+  svn_editor3_nbid_t nbid,
+  svn_editor3_nbid_t new_parent_nbid,
+  const char *new_name,
+  const svn_editor3_node_content_t *new_content,
   apr_pool_t *scratch_pool);
 
-/** @see svn_editor_abort(), svn_editor_t.
- * @since New in 1.8.
+/** @see svn_editor3_complete(), svn_editor3_t.
  */
-typedef svn_error_t *(*svn_editor_cb_abort_t)(
+typedef svn_error_t *(*svn_editor3_cb_complete_t)(
+  void *baton,
+  apr_pool_t *scratch_pool);
+
+/** @see svn_editor3_abort(), svn_editor3_t.
+ */
+typedef svn_error_t *(*svn_editor3_cb_abort_t)(
   void *baton,
   apr_pool_t *scratch_pool);
 
@@ -631,505 +880,155 @@ typedef svn_error_t *(*svn_editor_cb_abo
 
 /** These functions create an editor instance so that it can be driven.
  *
- * @defgroup svn_editor_create Editor creation
+ * @defgroup svn_editor3_create Editor creation
  * @{
  */
 
-/** Allocate an #svn_editor_t instance from @a result_pool, store
- * @a editor_baton, @a cancel_func and @a cancel_baton in the new instance
- * and return it in @a editor.
+/** A set of editor callback functions.
+ *
+ * If a function pointer is NULL, it will not be called.
+ *
+ * @see svn_editor3_create(), svn_editor3_t.
+ */
+typedef struct svn_editor3_cb_funcs_t
+{
+  svn_editor3_cb_mk_t cb_mk;
+  svn_editor3_cb_cp_t cb_cp;
+  svn_editor3_cb_mv_t cb_mv;
+  svn_editor3_cb_res_t cb_res;
+  svn_editor3_cb_rm_t cb_rm;
+  svn_editor3_cb_put_t cb_put;
+
+  svn_editor3_cb_add_t cb_add;
+  svn_editor3_cb_copy_one_t cb_copy_one;
+  svn_editor3_cb_copy_tree_t cb_copy_tree;
+  svn_editor3_cb_delete_t cb_delete;
+  svn_editor3_cb_alter_t cb_alter;
+
+  svn_editor3_cb_complete_t cb_complete;
+  svn_editor3_cb_abort_t cb_abort;
+
+} svn_editor3_cb_funcs_t;
+
+/** Allocate an #svn_editor3_t instance from @a result_pool, store
+ * @a *editor_funcs, @a editor_baton, @a cancel_func and @a cancel_baton
+ * in the new instance and return it in @a *editor.
+ *
  * @a scratch_pool is used for temporary allocations (if any). Note that
  * this is NOT the same @a scratch_pool that is passed to callback functions.
- * @see svn_editor_t
- * @since New in 1.8.
+ *
+ * @see svn_editor3_t
  */
 svn_error_t *
-svn_editor_create(svn_editor_t **editor,
-                  void *editor_baton,
-                  svn_cancel_func_t cancel_func,
-                  void *cancel_baton,
-                  apr_pool_t *result_pool,
-                  apr_pool_t *scratch_pool);
-
+svn_editor3_create(svn_editor3_t **editor,
+                   const svn_editor3_cb_funcs_t *editor_funcs,
+                   void *editor_baton,
+                   svn_cancel_func_t cancel_func,
+                   void *cancel_baton,
+                   apr_pool_t *result_pool,
+                   apr_pool_t *scratch_pool);
 
 /** Return an editor's private baton.
  *
  * In some cases, the baton is required outside of the callbacks. This
  * function returns the private baton for use.
- *
- * @since New in 1.8.
  */
 void *
-svn_editor_get_baton(const svn_editor_t *editor);
-
-
-/** Sets the #svn_editor_cb_add_directory_t callback in @a editor
- * to @a callback.
- * @a scratch_pool is used for temporary allocations (if any).
- * @see also svn_editor_setcb_many().
- * @since New in 1.8.
- */
-svn_error_t *
-svn_editor_setcb_add_directory(svn_editor_t *editor,
-                               svn_editor_cb_add_directory_t callback,
-                               apr_pool_t *scratch_pool);
-
-/** Sets the #svn_editor_cb_add_file_t callback in @a editor
- * to @a callback.
- * @a scratch_pool is used for temporary allocations (if any).
- * @see also svn_editor_setcb_many().
- * @since New in 1.8.
- */
-svn_error_t *
-svn_editor_setcb_add_file(svn_editor_t *editor,
-                          svn_editor_cb_add_file_t callback,
-                          apr_pool_t *scratch_pool);
-
-/** Sets the #svn_editor_cb_add_symlink_t callback in @a editor
- * to @a callback.
- * @a scratch_pool is used for temporary allocations (if any).
- * @see also svn_editor_setcb_many().
- * @since New in 1.8.
- */
-svn_error_t *
-svn_editor_setcb_add_symlink(svn_editor_t *editor,
-                             svn_editor_cb_add_symlink_t callback,
-                             apr_pool_t *scratch_pool);
-
-/** Sets the #svn_editor_cb_add_absent_t callback in @a editor
- * to @a callback.
- * @a scratch_pool is used for temporary allocations (if any).
- * @see also svn_editor_setcb_many().
- * @since New in 1.8.
- */
-svn_error_t *
-svn_editor_setcb_add_absent(svn_editor_t *editor,
-                            svn_editor_cb_add_absent_t callback,
-                            apr_pool_t *scratch_pool);
-
-/** Sets the #svn_editor_cb_alter_directory_t callback in @a editor
- * to @a callback.
- * @a scratch_pool is used for temporary allocations (if any).
- * @see also svn_editor_setcb_many().
- * @since New in 1.8.
- */
-svn_error_t *
-svn_editor_setcb_alter_directory(svn_editor_t *editor,
-                                 svn_editor_cb_alter_directory_t callback,
-                                 apr_pool_t *scratch_pool);
-
-/** Sets the #svn_editor_cb_alter_file_t callback in @a editor
- * to @a callback.
- * @a scratch_pool is used for temporary allocations (if any).
- * @see also svn_editor_setcb_many().
- * @since New in 1.8.
- */
-svn_error_t *
-svn_editor_setcb_alter_file(svn_editor_t *editor,
-                            svn_editor_cb_alter_file_t callback,
-                            apr_pool_t *scratch_pool);
-
-/** Sets the #svn_editor_cb_alter_symlink_t callback in @a editor
- * to @a callback.
- * @a scratch_pool is used for temporary allocations (if any).
- * @see also svn_editor_setcb_many().
- * @since New in 1.8.
- */
-svn_error_t *
-svn_editor_setcb_alter_symlink(svn_editor_t *editor,
-                               svn_editor_cb_alter_symlink_t callback,
-                               apr_pool_t *scratch_pool);
-
-/** Sets the #svn_editor_cb_delete_t callback in @a editor
- * to @a callback.
- * @a scratch_pool is used for temporary allocations (if any).
- * @see also svn_editor_setcb_many().
- * @since New in 1.8.
- */
-svn_error_t *
-svn_editor_setcb_delete(svn_editor_t *editor,
-                        svn_editor_cb_delete_t callback,
-                        apr_pool_t *scratch_pool);
-
-/** Sets the #svn_editor_cb_copy_t callback in @a editor
- * to @a callback.
- * @a scratch_pool is used for temporary allocations (if any).
- * @see also svn_editor_setcb_many().
- * @since New in 1.8.
- */
-svn_error_t *
-svn_editor_setcb_copy(svn_editor_t *editor,
-                      svn_editor_cb_copy_t callback,
-                      apr_pool_t *scratch_pool);
-
-/** Sets the #svn_editor_cb_move_t callback in @a editor
- * to @a callback.
- * @a scratch_pool is used for temporary allocations (if any).
- * @see also svn_editor_setcb_many().
- * @since New in 1.8.
- */
-svn_error_t *
-svn_editor_setcb_move(svn_editor_t *editor,
-                      svn_editor_cb_move_t callback,
-                      apr_pool_t *scratch_pool);
-
-/** Sets the #svn_editor_cb_complete_t callback in @a editor
- * to @a callback.
- * @a scratch_pool is used for temporary allocations (if any).
- * @see also svn_editor_setcb_many().
- * @since New in 1.8.
- */
-svn_error_t *
-svn_editor_setcb_complete(svn_editor_t *editor,
-                          svn_editor_cb_complete_t callback,
-                          apr_pool_t *scratch_pool);
-
-/** Sets the #svn_editor_cb_abort_t callback in @a editor
- * to @a callback.
- * @a scratch_pool is used for temporary allocations (if any).
- * @see also svn_editor_setcb_many().
- * @since New in 1.8.
- */
-svn_error_t *
-svn_editor_setcb_abort(svn_editor_t *editor,
-                       svn_editor_cb_abort_t callback,
-                       apr_pool_t *scratch_pool);
-
-
-/** Lists a complete set of editor callbacks.
- * This is a convenience structure.
- * @see svn_editor_setcb_many(), svn_editor_create(), svn_editor_t.
- * @since New in 1.8.
- */
-typedef struct svn_editor_cb_many_t
-{
-  svn_editor_cb_add_directory_t cb_add_directory;
-  svn_editor_cb_add_file_t cb_add_file;
-  svn_editor_cb_add_symlink_t cb_add_symlink;
-  svn_editor_cb_add_absent_t cb_add_absent;
-  svn_editor_cb_alter_directory_t cb_alter_directory;
-  svn_editor_cb_alter_file_t cb_alter_file;
-  svn_editor_cb_alter_symlink_t cb_alter_symlink;
-  svn_editor_cb_delete_t cb_delete;
-  svn_editor_cb_copy_t cb_copy;
-  svn_editor_cb_move_t cb_move;
-  svn_editor_cb_complete_t cb_complete;
-  svn_editor_cb_abort_t cb_abort;
-
-} svn_editor_cb_many_t;
-
-/** Sets all the callback functions in @a editor at once, according to the
- * callback functions stored in @a many.
- * @a scratch_pool is used for temporary allocations (if any).
- * @since New in 1.8.
- */
-svn_error_t *
-svn_editor_setcb_many(svn_editor_t *editor,
-                      const svn_editor_cb_many_t *many,
-                      apr_pool_t *scratch_pool);
+svn_editor3_get_baton(const svn_editor3_t *editor);
 
 /** @} */
 
 
-/** These functions are called by the tree delta driver to edit the target.
- *
- * @see svn_editor_t.
+/*
+ * ========================================================================
+ * Node Content Interface
+ * ========================================================================
  *
- * @defgroup svn_editor_drive Driving the editor
+ * @defgroup svn_editor3_node_content Node content interface
  * @{
  */
 
-/** Drive @a editor's #svn_editor_cb_add_directory_t callback.
+/** Versioned content of a node, excluding tree structure information.
  *
- * Create a new directory at @a relpath. The immediate parent of @a relpath
- * is expected to exist.
+ * The @a ref field specifies a reference content: the content of an
+ * existing committed node, or empty. The other fields are optional
+ * overrides for parts of the content.
  *
- * For descriptions of @a props and @a replaces_rev, see
- * svn_editor_add_file().
- *
- * A complete listing of the immediate children of @a relpath that will be
- * added subsequently is given in @a children. @a children is an array of
- * const char*s, each giving the basename of an immediate child. It is an
- * error to pass NULL for @a children; use an empty array to indicate
- * the new directory will have no children.
- *
- * For all restrictions on driving the editor, see #svn_editor_t.
+ * ### Specify content as deltas against the (optional) reference instead
+ *     of as overrides?
  */
-svn_error_t *
-svn_editor_add_directory(svn_editor_t *editor,
-                         const char *relpath,
-                         const apr_array_header_t *children,
-                         apr_hash_t *props,
-                         svn_revnum_t replaces_rev);
-
-/** Drive @a editor's #svn_editor_cb_add_file_t callback.
- *
- * Create a new file at @a relpath. The immediate parent of @a relpath
- * is expected to exist.
- *
- * The file's contents are specified in @a contents which has a checksum
- * matching @a checksum. Both values must be non-NULL.
- *
- * Set the properties of the new file to @a props, which is an
- * apr_hash_t holding key-value pairs. Each key is a const char* of a
- * property name, each value is a const svn_string_t*. If no properties are
- * being set on the new file, @a props must be the empty hash. It is an
- * error to pass NULL for @a props.
- *
- * If this add is expected to replace a previously existing file, symlink or
- * directory at @a relpath, the revision number of the node to be replaced
- * must be given in @a replaces_rev. Otherwise, @a replaces_rev must be
- * #SVN_INVALID_REVNUM.  Note: it is not allowed to call a "delete" followed
- * by an "add" on the same path. Instead, an "add" with @a replaces_rev set
- * accordingly MUST be used.
- *
- * For all restrictions on driving the editor, see #svn_editor_t.
- * @since New in 1.8.
- */
-svn_error_t *
-svn_editor_add_file(svn_editor_t *editor,
-                    const char *relpath,
-                    const svn_checksum_t *checksum,
-                    svn_stream_t *contents,
-                    apr_hash_t *props,
-                    svn_revnum_t replaces_rev);
-
-/** Drive @a editor's #svn_editor_cb_add_symlink_t callback.
- *
- * Create a new symbolic link at @a relpath, with a link target of @a
- * target. The immediate parent of @a relpath is expected to exist.
- *
- * For descriptions of @a props and @a replaces_rev, see
- * svn_editor_add_file().
- *
- * For all restrictions on driving the editor, see #svn_editor_t.
- * @since New in 1.8.
- */
-svn_error_t *
-svn_editor_add_symlink(svn_editor_t *editor,
-                       const char *relpath,
-                       const char *target,
-                       apr_hash_t *props,
-                       svn_revnum_t replaces_rev);
-
-/** Drive @a editor's #svn_editor_cb_add_absent_t callback.
- *
- * Create an "absent" node of kind @a kind at @a relpath. The immediate
- * parent of @a relpath is expected to exist.
- * ### TODO @todo explain "absent".
- * ### JAF: What are the allowed values of 'kind'?
- *
- * For a description of @a replaces_rev, see svn_editor_add_file().
- *
- * For all restrictions on driving the editor, see #svn_editor_t.
- * @since New in 1.8.
- */
-svn_error_t *
-svn_editor_add_absent(svn_editor_t *editor,
-                      const char *relpath,
-                      svn_node_kind_t kind,
-                      svn_revnum_t replaces_rev);
-
-/** Drive @a editor's #svn_editor_cb_alter_directory_t callback.
- *
- * Alter the properties of the directory at @a relpath.
- *
- * @a revision specifies the revision at which the receiver should
- * expect to find this node. That is, @a relpath at the start of the
- * whole edit and @a relpath at @a revision must lie within the same
- * node-rev (aka location history segment). This information may be used
- * to catch an attempt to alter and out-of-date directory. If the
- * directory does not have a corresponding revision in the repository
- * (e.g. it has not yet been committed), then @a revision should be
- * #SVN_INVALID_REVNUM.
- *
- * If any changes to the set of children will be made in the future of
- * the edit drive, then @a children MUST specify the resulting set of
- * children. See svn_editor_add_directory() for the format of @a children.
- * If not changes will be made, then NULL may be specified.
- *
- * For a description of @a props, see svn_editor_add_file(). If no changes
- * to the properties will be made (ie. only future changes to the set of
- * children), then @a props may be NULL.
- *
- * It is an error to pass NULL for both @a children and @a props.
- *
- * For all restrictions on driving the editor, see #svn_editor_t.
- * @since New in 1.8.
- */
-svn_error_t *
-svn_editor_alter_directory(svn_editor_t *editor,
-                           const char *relpath,
-                           svn_revnum_t revision,
-                           const apr_array_header_t *children,
-                           apr_hash_t *props);
-
-/** Drive @a editor's #svn_editor_cb_alter_file_t callback.
- *
- * Alter the properties and/or the contents of the file at @a relpath
- * with @a revision as its expected revision. See svn_editor_alter_directory()
- * for more information about @a revision.
- *
- * If @a props is non-NULL, then the properties will be applied.
- *
- * If @a contents is non-NULL, then the stream will be copied to
- * the file, and its checksum must match @a checksum (which must also
- * be non-NULL). If @a contents is NULL, then @a checksum must also
- * be NULL, and no change will be applied to the file's contents.
- *
- * The properties and/or the contents must be changed. It is an error to
- * pass NULL for @a props, @a checksum, and @a contents.
- *
- * For a description of @a checksum and @a contents see
- * svn_editor_add_file(). This function allows @a props to be NULL, but
- * the parameter is otherwise described by svn_editor_add_file().
- *
- * For all restrictions on driving the editor, see #svn_editor_t.
- * @since New in 1.8.
- */
-svn_error_t *
-svn_editor_alter_file(svn_editor_t *editor,
-                      const char *relpath,
-                      svn_revnum_t revision,
-                      const svn_checksum_t *checksum,
-                      svn_stream_t *contents,
-                      apr_hash_t *props);
+struct svn_editor3_node_content_t
+{
+  /* Reference the content in an existing, committed node-rev.
+   *
+   * If this is (SVN_INVALID_REVNUM, NULL) then the reference content
+   * is empty.
+   *
+   * ### Reference a whole node-rev instead? (Don't need to reference a
+   *     specific rev.)
+   */
+  pathrev_t ref;
 
-/** Drive @a editor's #svn_editor_cb_alter_symlink_t callback.
- *
- * Alter the properties and/or the target of the symlink at @a relpath
- * with @a revision as its expected revision. See svn_editor_alter_directory()
- * for more information about @a revision.
- *
- * If @a props is non-NULL, then the properties will be applied.
- *
- * If @a target is non-NULL, then the symlink's target will be updated.
- *
- * The properties and/or the target must be changed. It is an error to
- * pass NULL for @a props and @a target.
- *
- * This function allows @a props to be NULL, but the parameter is
- * otherwise described by svn_editor_add_file().
- *
- * For all restrictions on driving the editor, see #svn_editor_t.
- * @since New in 1.8.
- */
-svn_error_t *
-svn_editor_alter_symlink(svn_editor_t *editor,
-                         const char *relpath,
-                         svn_revnum_t revision,
-                         const char *target,
-                         apr_hash_t *props);
+  /* Properties (for all node kinds).
+   * Maps (const char *) name -> (svn_string_t) value. */
+  apr_hash_t *props;
 
-/** Drive @a editor's #svn_editor_cb_delete_t callback.
- *
- * Delete the existing node at @a relpath, expected to be identical to
- * revision @a revision of that path.
- *
- * For all restrictions on driving the editor, see #svn_editor_t.
- * @since New in 1.8.
- */
-svn_error_t *
-svn_editor_delete(svn_editor_t *editor,
-                  const char *relpath,
-                  svn_revnum_t revision);
+  /* Text checksum (only for a file; otherwise SHOULD be NULL). */
+  const svn_checksum_t *checksum;
 
-/** Drive @a editor's #svn_editor_cb_copy_t callback.
- *
- * Copy the node at @a src_relpath, expected to be identical to revision @a
- * src_revision of that path, to @a dst_relpath.
- *
- * For a description of @a replaces_rev, see svn_editor_add_file().
- *
- * @note See the general instructions on paths for this API. Since the
- * @a src_relpath argument must generally be able to reference any node
- * in the repository, the implication is that the editor's root must be
- * the repository root.
- *
- * For all restrictions on driving the editor, see #svn_editor_t.
- * @since New in 1.8.
+  /* Text stream, readable (only for a file; otherwise SHOULD be NULL).
+   * ### May be null if we expect the receiver to retrieve the text by its
+   *     checksum? */
+  svn_stream_t *stream;
+
+  /* Symlink target (only for a symlink; otherwise SHOULD be NULL). */
+  const char *target;
+
+};
+
+/* Duplicate a node-content into result_pool.
+ * ### What about the stream though? Maybe we shouldn't have a _dup.
  */
-svn_error_t *
-svn_editor_copy(svn_editor_t *editor,
-                const char *src_relpath,
-                svn_revnum_t src_revision,
-                const char *dst_relpath,
-                svn_revnum_t replaces_rev);
+/* svn_editor3_node_content_t *
+svn_editor3_node_content_dup(const svn_editor3_node_content_t *old,
+                             apr_pool_t *result_pool); */
 
-/** Drive @a editor's #svn_editor_cb_move_t callback.
- *
- * Move the node at @a src_relpath to @a dst_relpath.
- *
- * @a src_revision specifies the revision at which the receiver should
- * expect to find this node.  That is, @a src_relpath at the start of
- * the whole edit and @a src_relpath at @a src_revision must lie within
- * the same node-rev (aka history-segment).  This is just like the
- * revisions specified to svn_editor_delete().
+/* Create a new node-content object for a directory node.
  *
- * For a description of @a replaces_rev, see svn_editor_add_file().
- *
- * ### what happens if one side of this move is not "within" the receiver's
- * ### set of paths?
- *
- * For all restrictions on driving the editor, see #svn_editor_t.
- * @since New in 1.8.
- */
+ * Allocate it in @a result_pool. */
 svn_error_t *
-svn_editor_move(svn_editor_t *editor,
-                const char *src_relpath,
-                svn_revnum_t src_revision,
-                const char *dst_relpath,
-                svn_revnum_t replaces_rev);
+svn_editor3_node_content_create_dir(svn_editor3_node_content_t **content,
+                                    pathrev_t ref,
+                                    apr_hash_t *props,
+                                    apr_pool_t *result_pool);
 
-/** Drive @a editor's #svn_editor_cb_complete_t callback.
- *
- * Send word that the edit has been completed successfully.
+/* Create a new node-content object for a file node.
  *
- * For all restrictions on driving the editor, see #svn_editor_t.
- * @since New in 1.8.
- */
+ * Allocate it in @a result_pool. */
 svn_error_t *
-svn_editor_complete(svn_editor_t *editor);
+svn_editor3_node_content_create_file(svn_editor3_node_content_t **content,
+                                     pathrev_t ref,
+                                     apr_hash_t *props,
+                                     const svn_checksum_t *checksum,
+                                     svn_stream_t *stream,
+                                     apr_pool_t *result_pool);
 
-/** Drive @a editor's #svn_editor_cb_abort_t callback.
- *
- * Notify that the edit transmission was not successful.
- * ### TODO @todo Shouldn't we add a reason-for-aborting argument?
+/* Create a new node-content object for a symlink node.
  *
- * For all restrictions on driving the editor, see #svn_editor_t.
- * @since New in 1.8.
- */
+ * Allocate it in @a result_pool. */
 svn_error_t *
-svn_editor_abort(svn_editor_t *editor);
+svn_editor3_node_content_create_symlink(svn_editor3_node_content_t **content,
+                                        pathrev_t ref,
+                                        apr_hash_t *props,
+                                        const char *target,
+                                        apr_pool_t *result_pool);
 
 /** @} */
 
 /** @} */
 
-/** A temporary API which conditionally inserts a double editor shim
- * into the chain of delta editors.  Used for testing Editor v2.
- *
- * Whether or not the shims are inserted is controlled by a compile-time
- * option in libsvn_delta/compat.c.
- *
- * @note The use of these shims and this API will likely cause all kinds
- * of performance degredation.  (Which is actually a moot point since they
- * don't even work properly yet anyway.)
- */
-svn_error_t *
-svn_editor__insert_shims(const svn_delta_editor_t **deditor_out,
-                         void **dedit_baton_out,
-                         const svn_delta_editor_t *deditor_in,
-                         void *dedit_baton_in,
-                         const char *repos_root,
-                         const char *base_dir,
-                         svn_delta_shim_callbacks_t *shim_callbacks,
-                         apr_pool_t *result_pool,
-                         apr_pool_t *scratch_pool);
-
-
 #ifdef __cplusplus
 }
 #endif /* __cplusplus */
 
-#endif /* SVN_EDITOR_H */
+#endif /* SVN_EDITOR3_H */



Mime
View raw message