Subversion
 All Data Structures Files Functions Variables Typedefs Enumerations Enumerator Macros Groups Pages
Data Fields
svn_delta_editor_t Struct Reference

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

#include <svn_delta.h>

Data Fields

svn_error_t *(* set_target_revision )(void *edit_baton, svn_revnum_t target_revision, apr_pool_t *scratch_pool)
 Set the target revision for this edit to target_revision.
 
svn_error_t *(* open_root )(void *edit_baton, svn_revnum_t base_revision, apr_pool_t *result_pool, void **root_baton)
 Set *root_baton to a baton for the top directory of the change.
 
svn_error_t *(* delete_entry )(const char *path, svn_revnum_t revision, void *parent_baton, apr_pool_t *scratch_pool)
 Remove the directory entry at path, a child of the directory represented by parent_baton.
 
svn_error_t *(* add_directory )(const char *path, void *parent_baton, const char *copyfrom_path, svn_revnum_t copyfrom_revision, apr_pool_t *result_pool, void **child_baton)
 We are going to add a new subdirectory at path, a child of the directory represented by parent_baton.
 
svn_error_t *(* open_directory )(const char *path, void *parent_baton, svn_revnum_t base_revision, apr_pool_t *result_pool, void **child_baton)
 We are going to make changes in the subdirectory at path, a child of the directory represented by parent_baton.
 
svn_error_t *(* change_dir_prop )(void *dir_baton, const char *name, const svn_string_t *value, apr_pool_t *scratch_pool)
 Change the value of a directory's property.
 
svn_error_t *(* close_directory )(void *dir_baton, apr_pool_t *scratch_pool)
 We are done processing a subdirectory, whose baton is dir_baton (set by add_directory or open_directory).
 
svn_error_t *(* absent_directory )(const char *path, void *parent_baton, apr_pool_t *scratch_pool)
 In the directory represented by parent_baton, indicate that path is present as a subdirectory in the edit source, but cannot be conveyed to the edit consumer.
 
svn_error_t *(* add_file )(const char *path, void *parent_baton, const char *copyfrom_path, svn_revnum_t copyfrom_revision, apr_pool_t *result_pool, void **file_baton)
 We are going to add a new file at path, a child of the directory represented by parent_baton.
 
svn_error_t *(* open_file )(const char *path, void *parent_baton, svn_revnum_t base_revision, apr_pool_t *result_pool, void **file_baton)
 We are going to make changes to a file at path, a child of the directory represented by parent_baton.
 
svn_error_t *(* apply_textdelta )(void *file_baton, const char *base_checksum, apr_pool_t *result_pool, svn_txdelta_window_handler_t *handler, void **handler_baton)
 Apply a text delta, yielding the new revision of a file.
 
svn_error_t *(* change_file_prop )(void *file_baton, const char *name, const svn_string_t *value, apr_pool_t *scratch_pool)
 Change the value of a file's property.
 
svn_error_t *(* close_file )(void *file_baton, const char *text_checksum, apr_pool_t *scratch_pool)
 We are done processing a file, whose baton is file_baton (set by add_file or open_file).
 
svn_error_t *(* absent_file )(const char *path, void *parent_baton, apr_pool_t *scratch_pool)
 In the directory represented by parent_baton, indicate that path is present as a file in the edit source, but cannot be cannot be conveyed to the edit consumer.
 
svn_error_t *(* close_edit )(void *edit_baton, apr_pool_t *scratch_pool)
 All delta processing is done.
 
svn_error_t *(* abort_edit )(void *edit_baton, apr_pool_t *scratch_pool)
 The editor-driver has decided to bail out.
 

Detailed Description

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 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:

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 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.
  1. The producer may not close a directory baton until it has closed all batons for its subdirectories.
  1. 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.
  1. 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.
  1. 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, 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 and close_file calls.

  1. 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 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 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 dir_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.

Definition at line 846 of file svn_delta.h.

Field Documentation

svn_error_t*(* svn_delta_editor_t::abort_edit)(void *edit_baton, apr_pool_t *scratch_pool)

The editor-driver has decided to bail out.

Allow the editor to gracefully clean up things if it needs to.

Any temporary allocations may be performed in scratch_pool.

Definition at line 1115 of file svn_delta.h.

svn_error_t*(* svn_delta_editor_t::absent_directory)(const char *path, void *parent_baton, apr_pool_t *scratch_pool)

In the directory represented by parent_baton, indicate that path is present as a subdirectory in the edit source, but cannot be conveyed to the edit consumer.

Currently, this would only occur because of authorization restrictions, but may change in the future.

Any temporary allocations may be performed in scratch_pool.

Definition at line 973 of file svn_delta.h.

svn_error_t*(* svn_delta_editor_t::absent_file)(const char *path, void *parent_baton, apr_pool_t *scratch_pool)

In the directory represented by parent_baton, indicate that path is present as a file in the edit source, but cannot be cannot be conveyed to the edit consumer.

Currently, this would only occur because of authorization restrictions, but may change in the future.

Any temporary allocations may be performed in scratch_pool.

Definition at line 1098 of file svn_delta.h.

svn_error_t*(* svn_delta_editor_t::add_directory)(const char *path, void *parent_baton, const char *copyfrom_path, svn_revnum_t copyfrom_revision, apr_pool_t *result_pool, void **child_baton)

We are going to add a new subdirectory at path, a child of the directory represented by parent_baton.

We will use the value this callback stores in *child_baton as the parent baton for further changes in the new subdirectory.

If copyfrom_path is non-NULL, this add has history (i.e., is a copy), and the origin of the copy may be recorded as copyfrom_path under copyfrom_revision.

Allocations for the returned child_baton should be performed in result_pool. It is also typical to (possibly) save this pool for later usage by close_directory.

Definition at line 914 of file svn_delta.h.

svn_error_t*(* svn_delta_editor_t::add_file)(const char *path, void *parent_baton, const char *copyfrom_path, svn_revnum_t copyfrom_revision, apr_pool_t *result_pool, void **file_baton)

We are going to add a new file at path, a child of the directory represented by parent_baton.

The callback can store a baton for this new file in **file_baton; whatever value it stores there should be passed through to apply_textdelta.

If copyfrom_path is non-NULL, this add has history (i.e., is a copy), and the origin of the copy may be recorded as copyfrom_path under copyfrom_revision.

Allocations for the returned file_baton should be performed in result_pool. It is also typical to save this pool for later usage by apply_textdelta and possibly close_file.

Note
Because the editor driver could be employing the "postfix deltas" paradigm, result_pool could potentially be relatively long-lived. Every file baton created by the editor for a given editor drive might be resident in memory similtaneously. Editor implementations should ideally keep their file batons as conservative (memory-usage-wise) as possible, and use result_pool only for those batons. (Consider using a subpool of result_pool for scratch work, destroying the subpool before exiting this function's implementation.)

Definition at line 1000 of file svn_delta.h.

svn_error_t*(* svn_delta_editor_t::apply_textdelta)(void *file_baton, const char *base_checksum, apr_pool_t *result_pool, svn_txdelta_window_handler_t *handler, void **handler_baton)

Apply a text delta, yielding the new revision of a file.

file_baton indicates the file we're creating or updating, and the ancestor file on which it is based; it is the baton set by some prior add_file or open_file callback.

The callback should set *handler to a text delta window handler; we will then call *handler on successive text delta windows as we receive them. The callback should set *handler_baton to the value we should pass as the baton argument to *handler. These values should be allocated within result_pool.

base_checksum is the hex MD5 digest for the base text against which the delta is being applied; it is ignored if NULL, and may be ignored even if not NULL. If it is not ignored, it must match the checksum of the base text against which svndiff data is being applied; if it does not, apply_textdelta or the *handler call which detects the mismatch will return the error SVN_ERR_CHECKSUM_MISMATCH (if there is no base text, there may still be an error if base_checksum is neither NULL nor the hex MD5 checksum of the empty string).

Definition at line 1051 of file svn_delta.h.

svn_error_t*(* svn_delta_editor_t::change_dir_prop)(void *dir_baton, const char *name, const svn_string_t *value, apr_pool_t *scratch_pool)

Change the value of a directory's property.

  • dir_baton specifies the directory whose property should change.
  • name is the name of the property to change.
  • value is the new (final) value of the property, or NULL if the property should be removed altogether.

The callback is guaranteed to be called exactly once for each property whose value differs between the start and the end of the edit.

Any temporary allocations may be performed in scratch_pool.

Definition at line 949 of file svn_delta.h.

svn_error_t*(* svn_delta_editor_t::change_file_prop)(void *file_baton, const char *name, const svn_string_t *value, apr_pool_t *scratch_pool)

Change the value of a file's property.

  • file_baton specifies the file whose property should change.
  • name is the name of the property to change.
  • value is the new (final) value of the property, or NULL if the property should be removed altogether.

The callback is guaranteed to be called exactly once for each property whose value differs between the start and the end of the edit.

Any temporary allocations may be performed in scratch_pool.

Definition at line 1068 of file svn_delta.h.

svn_error_t*(* svn_delta_editor_t::close_directory)(void *dir_baton, apr_pool_t *scratch_pool)

We are done processing a subdirectory, whose baton is dir_baton (set by add_directory or open_directory).

We won't be using the baton any more, so whatever resources it refers to may now be freed.

Any temporary allocations may be performed in scratch_pool.

Definition at line 961 of file svn_delta.h.

svn_error_t*(* svn_delta_editor_t::close_edit)(void *edit_baton, apr_pool_t *scratch_pool)

All delta processing is done.

Call this, with the edit_baton for the entire edit.

Any temporary allocations may be performed in scratch_pool.

Definition at line 1107 of file svn_delta.h.

svn_error_t*(* svn_delta_editor_t::close_file)(void *file_baton, const char *text_checksum, apr_pool_t *scratch_pool)

We are done processing a file, whose baton is file_baton (set by add_file or open_file).

We won't be using the baton any more, so whatever resources it refers to may now be freed.

text_checksum is the hex MD5 digest for the fulltext that resulted from a delta application, see apply_textdelta. The checksum is ignored if NULL. If not null, it is compared to the checksum of the new fulltext, and the error SVN_ERR_CHECKSUM_MISMATCH is returned if they do not match. If there is no new fulltext, text_checksum is ignored.

Any temporary allocations may be performed in scratch_pool.

Definition at line 1086 of file svn_delta.h.

svn_error_t*(* svn_delta_editor_t::delete_entry)(const char *path, svn_revnum_t revision, void *parent_baton, apr_pool_t *scratch_pool)

Remove the directory entry at path, a child of the directory represented by parent_baton.

If revision is a valid revision number, it is used as a sanity check to ensure that you are really removing the revision of path that you think you are.

Any temporary allocations may be performed in scratch_pool.

Note
The revision parameter is typically used only for client->server commit-type operations, allowing the server to verify that it is deleting what the client thinks it should be deleting. It only really makes sense in the opposite direction (during server->client update-type operations) when the trees whose delta is being described are ancestrally related (that is, one tree is an ancestor of the other).

Definition at line 895 of file svn_delta.h.

svn_error_t*(* svn_delta_editor_t::open_directory)(const char *path, void *parent_baton, svn_revnum_t base_revision, apr_pool_t *result_pool, void **child_baton)

We are going to make changes in the subdirectory at path, a child of the directory represented by parent_baton.

The callback must store a value in *child_baton that should be used as the parent baton for subsequent changes in this subdirectory. If a valid revnum, base_revision is the current revision of the subdirectory.

Allocations for the returned child_baton should be performed in result_pool. It is also typical to (possibly) save this pool for later usage by close_directory.

Definition at line 932 of file svn_delta.h.

svn_error_t*(* svn_delta_editor_t::open_file)(const char *path, void *parent_baton, svn_revnum_t base_revision, apr_pool_t *result_pool, void **file_baton)

We are going to make changes to a file at path, a child of the directory represented by parent_baton.

The callback can store a baton for this new file in **file_baton; whatever value it stores there should be passed through to apply_textdelta. If a valid revnum, base_revision is the current revision of the file.

Allocations for the returned file_baton should be performed in result_pool. It is also typical to save this pool for later usage by apply_textdelta and possibly close_file.

Note
See note about memory usage on add_file, which also applies here.

Definition at line 1022 of file svn_delta.h.

svn_error_t*(* svn_delta_editor_t::open_root)(void *edit_baton, svn_revnum_t base_revision, apr_pool_t *result_pool, void **root_baton)

Set *root_baton to a baton for the top directory of the change.

(This is the top of the subtree being changed, not necessarily the root of the filesystem.) As with any other directory baton, the producer should call close_directory on root_baton when done. And as with other open_* calls, the base_revision here is the current revision of the directory (before getting bumped up to the new target revision set with set_target_revision).

Allocations for the returned root_baton should be performed in result_pool. It is also typical to (possibly) save this pool for later usage by close_directory.

Definition at line 874 of file svn_delta.h.

svn_error_t*(* svn_delta_editor_t::set_target_revision)(void *edit_baton, svn_revnum_t target_revision, apr_pool_t *scratch_pool)

Set the target revision for this edit to target_revision.

This call, if used, should precede all other editor calls.

Note
This is typically used only for server->client update-type operations. It doesn't really make much sense for commit-type operations, because the revision of a commit isn't known until the commit is finalized.

Any temporary allocations may be performed in scratch_pool.

Definition at line 858 of file svn_delta.h.


The documentation for this struct was generated from the following file: