Tree deltas
Delta generation and handling

Traversing tree deltas. More...

## Data Structures

struct | svn_delta_editor_t
| A structure full of callback functions the delta source will invoke as it produces the delta. More...

## Typedefs

typedef struct svn_delta_editor_t | svn_delta_editor_t
| A structure full of callback functions the delta source will invoke as it produces the delta. More...

## Functions

svn_delta_editor_t * | svn_delta_default_editor (apr_pool_t *pool)
| Return a default delta editor template, allocated in pool. More...
svn_error_t * | svn_delta_noop_window_handler (svn_txdelta_window_t *window, void *baton)
| A text-delta window handler which does nothing. More...
svn_error_t * | svn_delta_get_cancellation_editor (svn_cancel_func_t cancel_func, void *cancel_baton, const svn_delta_editor_t *wrapped_editor, void *wrapped_baton, const svn_delta_editor_t **editor, void **edit_baton, apr_pool_t *pool)
| Set *editor and *edit_baton to a cancellation editor that wraps wrapped_editor and wrapped_baton. More...
svn_error_t * | svn_delta_depth_filter_editor (const svn_delta_editor_t **editor, void **edit_baton, const svn_delta_editor_t *wrapped_editor, void *wrapped_edit_baton, svn_depth_t requested_depth, svn_boolean_t has_target, apr_pool_t *pool)
| Set *editor and *edit_baton to an depth-based filtering editor that wraps wrapped_editor and wrapped_baton. More...

## Detailed Description

Traversing tree deltas.

In Subversion, we've got various producers and consumers of tree deltas.

In processing a ‘commit’ command:

- The client examines its working copy data, and produces a tree delta describing the changes to be committed.
- The client networking library consumes that delta, and sends them 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 produces a tree delta — hopefully equivalent to the one the client produced above.
- The Subversion server module consumes that delta and commits an appropriate transaction to the filesystem.

In processing an ‘update’ command, the process is reversed:

- The Subversion server module talks to the filesystem and produces a tree delta describing the changes necessary to bring the client's working copy up to date.
- The server consumes this delta, and assembles a reply representing the appropriate changes.
- The client networking library receives that reply, and produces a tree delta — hopefully equivalent to the one the Subversion server produced above.
- The working copy library consumes that delta, and makes the appropriate changes to the working copy.

The simplest approach would be to represent tree deltas using the obvious data structure. To do an update, the server would construct a delta structure, and the working copy library would apply that structure to the working copy; the network layer's job would simply be to get the structure across the net intact.

However, we expect that these deltas will occasionally be too large to fit in a typical workstation's swap area. For example, in checking out a 200Mb source tree, the entire source tree is represented by a single tree delta. So it's important to handle deltas that are too large to fit in swap all at once.

So instead of representing the tree delta explicitly, we define a standard way for a consumer to process each piece of a tree delta as soon as the producer creates it. The svn_delta_editor_t structure is a set of callback functions to be defined by a delta consumer, and invoked by a delta producer. Each invocation of a callback function describes a piece of the delta — a file's contents changing, something being renamed, etc.

## Typedef Documentation

## svn_delta_editor_t

typedef struct svn_delta_editor_t svn_delta_editor_t

A structure full of callback functions the delta source will invoke as it produces the delta.

Note
  Don't try to allocate one of these yourself. Instead, always use svn_delta_default_editor() or some other constructor, to avoid backwards compatibility problems if the structure is extended in future releases and to ensure that unused slots are filled in with no-op functions.

### Function Usage

Here's how to use these functions to express a tree delta.

The delta consumer implements the callback functions described in this structure, and the delta producer invokes them. So the caller (producer) is pushing tree delta data at the callee (consumer).

At the start of traversal, the consumer provides edit_baton, a baton global to the entire delta edit. If there is a target revision that needs to be set for this operation, the producer should call the `set_target_revision` function at this point.

Next, if there are any tree deltas to express, the producer should pass the edit_baton to the `open_root` function, to get a baton representing root of the tree being edited.

Most of the callbacks work in the obvious way:

    @c delete_entry
    @c add_file
    @c add_directory
    @c open_file
    @c open_directory

Each of these takes a directory baton, indicating the directory in which the change takes place, and a path argument, giving the path of the file, subdirectory, or directory entry to change.

The path argument to each of the callbacks is relative to the root of the edit. Editors will usually want to join this relative path with some base stored in the edit baton (e.g. a URL, or a location in the OS filesystem).

Since every call requires a parent directory baton, including `add_directory` and `open_directory`, where do we ever get our initial directory baton, to get things started? The `open_root` function returns a baton for the top directory of the change. In general, the producer needs to invoke the editor's `open_root` function before it can get anything of interest done.

While `open_root` provides a directory baton for the root of the tree being changed, the `add_directory` and `open_directory` callbacks provide batons for other directories. Like the callbacks above, they take a parent_baton and a relative path path, and then return a new baton for the subdirectory being created / modified — child_baton. The producer can then use child_baton to make further changes in that subdirectory.

So, if we already have subdirectories named ‘foo’ and ‘foo/bar’, then the producer can create a new file named ‘foo/bar/baz.c’ by calling:

- `open_root` () — yielding a baton root for the top directory
- `open_directory` (root, "foo") — yielding a baton f for ‘foo’
- `open_directory` (f, "foo/bar") — yielding a baton b for ‘foo/bar’
- `add_file` (b, "foo/bar/baz.c")

When the producer is finished making changes to a directory, it should call `close_directory`. This lets the consumer do any necessary cleanup, and free the baton's storage.

The `add_file` and `open_file` callbacks each return a baton for the file being created or changed. This baton can then be passed to `apply_textdelta` or `apply_textdelta_stream` to change the file's contents, or `change_file_prop` to change the file's properties. When the producer is finished making changes to a file, it should call `close_file`, to let the consumer clean up and free the baton.

The `add_file` and `add_directory` functions each take arguments copyfrom_path and copyfrom_revision. If copyfrom_path is non-`NULL`, then copyfrom_path and copyfrom_revision indicate where the file or directory should be copied from (to create the file or directory being added). In that case, copyfrom_path must be either a path relative to the root of the edit, or a URI from the repository being edited. If copyfrom_path is `NULL`, then copyfrom_revision must be SVN_INVALID_REVNUM; it is invalid to pass a mix of valid and invalid copyfrom arguments.

### Function Call Ordering

There are six restrictions on the order in which the producer may use the batons:

1. The producer may call `open_directory`, `add_directory`, `open_file`, `add_file` at most once on any given directory entry. `delete_entry` may be called at most once on any given directory entry and may later be followed by `add_directory` or `add_file` on the same directory entry. `delete_entry` may not be called on any directory entry after `open_directory`, `add_directory`, `open_file` or `add_file` has been called on that directory entry.
2. The producer may not close a directory baton until it has closed all batons for its subdirectories.
3. When a producer calls `open_directory` or `add_directory`, it must specify the most recently opened of the currently open directory batons. Put another way, the producer cannot have two sibling directory batons open at the same time.
4. A producer must call `change_dir_prop` on a directory either before opening any of the directory's subdirs or after closing them, but not in the middle.

5. When the producer calls `open_file` or `add_file`, either:

   (a) The producer must follow with any changes to the file (`change_file_prop` and/or `apply_textdelta` / `apply_textdelta_stream`, as applicable), followed by a `close_file` call, before issuing any other file or directory calls, or

   (b) The producer must follow with a `change_file_prop` call if it is applicable, before issuing any other file or directory calls; later, after all directory batons including the root have been closed, the producer must issue `apply_textdelta` / `apply_textdelta_stream` and `close_file` calls.

6. When the producer calls `apply_textdelta`, it must make all of the window handler calls (including the `NULL` window at the end) before issuing any other svn_delta_editor_t calls.

So, the producer needs to use directory and file batons as if it is doing a single depth-first traversal of the tree, with the exception that the producer may keep file batons open in order to make `apply_textdelta` / `apply_textdelta_stream` calls at the end.

### Pool Usage

Many editor functions are invoked multiple times, in a sequence determined by the editor "driver". The driver is responsible for creating a pool for use on each iteration of the editor function, and clearing that pool between each iteration. The driver passes the appropriate pool on each function invocation.

Based on the requirement of calling the editor functions in a depth-first style, it is usually customary for the driver to similarly nest the pools. However, this is only a safety feature to ensure that pools associated with deeper items are always cleared when the top-level items are also cleared. The interface does not assume, nor require, any particular organization of the pools passed to these functions. In fact, if "postfix deltas" are used for files, the file pools definitely need to live outside the scope of their parent directories' pools.

Note that close_directory can be called before a file in that directory has been closed. That is, the directory's baton is closed before the file's baton. The implication is that `apply_textdelta` / `apply_textdelta_stream` and `close_file` should not refer to a parent directory baton UNLESS the editor has taken precautions to allocate it in a pool of the appropriate lifetime (the result_pool passed to `open_directory` and `add_directory` definitely does not have the proper lifetime). In general, it is recommended to simply avoid keeping a parent directory baton in a file baton.

### Errors

At least one implementation of the editor interface is asynchronous; an error from one operation may be detected some number of operations later. As a result, an editor driver must not assume that an error from an editing function resulted from the particular operation being detected. Moreover, once an editing function (including `close_edit`) returns an error, the edit is dead; the only further operation which may be called on the editor is `abort_edit`.

## Function Documentation

## svn_delta_default_editor()

svn_delta_editor_t* svn_delta_default_editor | ( | apr_pool_t * | pool | ) |

Return a default delta editor template, allocated in pool.

The editor functions in the template do only the most basic baton-swapping: each editor function that produces a baton does so by copying its incoming baton into the outgoing baton reference.

This editor is not intended to be useful by itself, but is meant to be the basis for a useful editor. After getting a default editor, you substitute in your own implementations for the editor functions you care about. The ones you don't care about, you don't have to implement – you can rely on the template's implementation to safely do nothing of consequence.

## svn_delta_depth_filter_editor()

svn_error_t* svn_delta_depth_filter_editor | ( | const svn_delta_editor_t ** | editor,
|  | void ** | edit_baton,
|  | const svn_delta_editor_t * | wrapped_editor,
|  | void * | wrapped_edit_baton,
|  | svn_depth_t | requested_depth,
|  | svn_boolean_t | has_target,
|  | apr_pool_t * | pool
| ) |  |

Set *editor and *edit_baton to an depth-based filtering editor that wraps wrapped_editor and wrapped_baton.

The editor will track the depth of this drive against the requested_depth, taking into account whether not the edit drive is making use of a target (via has_target), and forward editor calls which operate "within" the request depth range through to wrapped_editor.

requested_depth must be one of the following depth values: svn_depth_infinity, svn_depth_empty, svn_depth_files, svn_depth_immediates, or svn_depth_unknown.

If filtering is deemed unnecessary (or if requested_depth is svn_depth_unknown), *editor and *edit_baton will be set to wrapped_editor and wrapped_baton, respectively; otherwise, they'll be set to new objects allocated from pool.

Note
  Because the svn_delta_editor_t interface's `delete_entry()` function doesn't carry node kind information, a depth-based filtering editor being asked to filter for svn_depth_files but receiving a `delete_entry()` call on an immediate child of the editor's target is unable to know if that deletion should be allowed or filtered out – a delete of a top-level file is okay in this case, a delete of a top-level subdirectory is not. As such, this filtering editor takes a conservative approach, and ignores top-level deletion requests when filtering for svn_depth_files. Fortunately, most non-depth-aware (pre-1.5) Subversion editor drivers can be told to drive non-recursively (where non-recursive means essentially svn_depth_files), which means they won't transmit out-of-scope editor commands anyway.

Since
  New in 1.5.

## svn_delta_get_cancellation_editor()

svn_error_t* svn_delta_get_cancellation_editor | ( | svn_cancel_func_t | cancel_func,
|  | void * | cancel_baton,
|  | const svn_delta_editor_t * | wrapped_editor,
|  | void * | wrapped_baton,
|  | const svn_delta_editor_t ** | editor,
|  | void ** | edit_baton,
|  | apr_pool_t * | pool
| ) |  |

Set *editor and *edit_baton to a cancellation editor that wraps wrapped_editor and wrapped_baton.

The editor will call cancel_func with cancel_baton when each of its functions is called, continuing on to call the corresponding wrapped function if cancel_func returns SVN_NO_ERROR.

If cancel_func is `NULL`, set *editor to wrapped_editor and *edit_baton to wrapped_baton.

## svn_delta_noop_window_handler()

svn_error_t* svn_delta_noop_window_handler | ( | svn_txdelta_window_t * | window,
|  | void * | baton
| ) |  |

A text-delta window handler which does nothing.

Editors can return this handler from `apply_textdelta` if they don't care about text delta windows.