Struct svn_delta_editor_t 

#[repr(C)]
pub struct svn_delta_editor_t {

    pub set_target_revision: Option<unsafe extern "C" fn(edit_baton: *mut c_void, target_revision: svn_revnum_t, scratch_pool: *mut apr_pool_t) -> *mut svn_error_t>,
    pub open_root: Option<unsafe extern "C" fn(edit_baton: *mut c_void, base_revision: svn_revnum_t, result_pool: *mut apr_pool_t, root_baton: *mut *mut c_void) -> *mut svn_error_t>,
    pub delete_entry: Option<unsafe extern "C" fn(path: *const c_char, revision: svn_revnum_t, parent_baton: *mut c_void, scratch_pool: *mut apr_pool_t) -> *mut svn_error_t>,
    pub add_directory: Option<unsafe extern "C" fn(path: *const c_char, parent_baton: *mut c_void, copyfrom_path: *const c_char, copyfrom_revision: svn_revnum_t, result_pool: *mut apr_pool_t, child_baton: *mut *mut c_void) -> *mut svn_error_t>,
    pub open_directory: Option<unsafe extern "C" fn(path: *const c_char, parent_baton: *mut c_void, base_revision: svn_revnum_t, result_pool: *mut apr_pool_t, child_baton: *mut *mut c_void) -> *mut svn_error_t>,
    pub change_dir_prop: Option<unsafe extern "C" fn(dir_baton: *mut c_void, name: *const c_char, value: *const svn_string_t, scratch_pool: *mut apr_pool_t) -> *mut svn_error_t>,
    pub close_directory: Option<unsafe extern "C" fn(dir_baton: *mut c_void, scratch_pool: *mut apr_pool_t) -> *mut svn_error_t>,
    pub absent_directory: Option<unsafe extern "C" fn(path: *const c_char, parent_baton: *mut c_void, scratch_pool: *mut apr_pool_t) -> *mut svn_error_t>,
    pub add_file: Option<unsafe extern "C" fn(path: *const c_char, parent_baton: *mut c_void, copyfrom_path: *const c_char, copyfrom_revision: svn_revnum_t, result_pool: *mut apr_pool_t, file_baton: *mut *mut c_void) -> *mut svn_error_t>,
    pub open_file: Option<unsafe extern "C" fn(path: *const c_char, parent_baton: *mut c_void, base_revision: svn_revnum_t, result_pool: *mut apr_pool_t, file_baton: *mut *mut c_void) -> *mut svn_error_t>,
    pub apply_textdelta: Option<unsafe extern "C" fn(file_baton: *mut c_void, base_checksum: *const c_char, result_pool: *mut apr_pool_t, handler: *mut svn_txdelta_window_handler_t, handler_baton: *mut *mut c_void) -> *mut svn_error_t>,
    pub change_file_prop: Option<unsafe extern "C" fn(file_baton: *mut c_void, name: *const c_char, value: *const svn_string_t, scratch_pool: *mut apr_pool_t) -> *mut svn_error_t>,
    pub close_file: Option<unsafe extern "C" fn(file_baton: *mut c_void, text_checksum: *const c_char, scratch_pool: *mut apr_pool_t) -> *mut svn_error_t>,
    pub absent_file: Option<unsafe extern "C" fn(path: *const c_char, parent_baton: *mut c_void, scratch_pool: *mut apr_pool_t) -> *mut svn_error_t>,
    pub close_edit: Option<unsafe extern "C" fn(edit_baton: *mut c_void, scratch_pool: *mut apr_pool_t) -> *mut svn_error_t>,
    pub abort_edit: Option<unsafe extern "C" fn(edit_baton: *mut c_void, scratch_pool: *mut apr_pool_t) -> *mut svn_error_t>,
    pub apply_textdelta_stream: Option<unsafe extern "C" fn(editor: *const svn_delta_editor_t, file_baton: *mut c_void, base_checksum: *const c_char, open_func: svn_txdelta_stream_open_func_t, open_baton: *mut c_void, scratch_pool: *mut apr_pool_t) -> *mut svn_error_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 @a 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 @c set_target_revision function at this point.

Next, if there are any tree deltas to express, the producer should pass the @a edit_baton to the @c 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 @a path argument, giving the path of the file, subdirectory, or directory entry to change.

The @a 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 @c add_directory and @c open_directory, where do we ever get our initial directory baton, to get things started? The @c open_root function returns a baton for the top directory of the change. In general, the producer needs to invoke the editor’s @c open_root function before it can get anything of interest done.

While @c open_root provides a directory baton for the root of the tree being changed, the @c add_directory and @c open_directory callbacks provide batons for other directories. Like the callbacks above, they take a @a parent_baton and a relative path @a path, and then return a new baton for the subdirectory being created / modified — @a child_baton. The producer can then use @a 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:

• @c open_root () — yielding a baton @a root for the top directory

• @c open_directory (@a root, “foo”) — yielding a baton @a f for `foo’

• @c open_directory (@a f, “foo/bar”) — yielding a baton @a b for `foo/bar’

• @c add_file (@a b, “foo/bar/baz.c”)

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

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

The @c add_file and @c add_directory functions each take arguments @a copyfrom_path and @a copyfrom_revision. If @a copyfrom_path is non-@c NULL, then @a copyfrom_path and @a copyfrom_revision indicate where the file or directory should be copied from (to create the file or directory being added). In that case, @a copyfrom_path must be either a path relative to the root of the edit, or a URI from the repository being edited. If @a copyfrom_path is @c NULL, then @a 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 @c open_directory, @c add_directory, @c open_file, @c add_file at most once on any given directory entry. @c delete_entry may be called at most once on any given directory entry and may later be followed by @c add_directory or @c add_file on the same directory entry. @c delete_entry may not be called on any directory entry after @c open_directory, @c add_directory, @c open_file or @c 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 @c open_directory or @c 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 @c 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 @c open_file or @c add_file, either:

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

   (b) The producer must follow with a @c 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 @c apply_textdelta / @c apply_textdelta_stream and @c close_file calls.

6. When the producer calls @c apply_textdelta, it must make all of the window handler calls (including the @c 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 @c apply_textdelta / @c 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 @c apply_textdelta / @c apply_textdelta_stream and @c 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 @a result_pool passed to @c open_directory and @c 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 @c close_edit) returns an error, the edit is dead; the only further operation which may be called on the editor is @c abort_edit.

Fields

set_target_revision: Option<unsafe extern "C" fn(edit_baton: *mut c_void, target_revision: svn_revnum_t, scratch_pool: *mut apr_pool_t) -> *mut svn_error_t>

Set the target revision for this edit to @a 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 @a scratch_pool.

open_root: Option<unsafe extern "C" fn(edit_baton: *mut c_void, base_revision: svn_revnum_t, result_pool: *mut apr_pool_t, root_baton: *mut *mut c_void) -> *mut svn_error_t>

Set @a 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 @c close_directory on @a root_baton when done. And as with other @c open_ calls, the @a base_revision here is the current revision of the directory (before getting bumped up to the new target revision set with @c set_target_revision).

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

delete_entry: Option<unsafe extern "C" fn(path: *const c_char, revision: svn_revnum_t, parent_baton: *mut c_void, scratch_pool: *mut apr_pool_t) -> *mut svn_error_t>

Remove the directory entry at @a path, a child of the directory represented by @a parent_baton. If @a revision is a valid revision number, it is used as a sanity check to ensure that you are really removing the revision of @a path that you think you are.

Any temporary allocations may be performed in @a scratch_pool.

@note The @a 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).

add_directory: Option<unsafe extern "C" fn(path: *const c_char, parent_baton: *mut c_void, copyfrom_path: *const c_char, copyfrom_revision: svn_revnum_t, result_pool: *mut apr_pool_t, child_baton: *mut *mut c_void) -> *mut svn_error_t>

We are going to add a new subdirectory at @a path, a child of the directory represented by @a parent_baton. We will use the value this callback stores in @a *child_baton as the parent baton for further changes in the new subdirectory.

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

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

open_directory: Option<unsafe extern "C" fn(path: *const c_char, parent_baton: *mut c_void, base_revision: svn_revnum_t, result_pool: *mut apr_pool_t, child_baton: *mut *mut c_void) -> *mut svn_error_t>

We are going to make changes in the subdirectory at @a path, a child of the directory represented by @a parent_baton. The callback must store a value in @a *child_baton that should be used as the parent baton for subsequent changes in this subdirectory. If a valid revnum, @a base_revision is the current revision of the subdirectory.

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

change_dir_prop: Option<unsafe extern "C" fn(dir_baton: *mut c_void, name: *const c_char, value: *const svn_string_t, scratch_pool: *mut apr_pool_t) -> *mut svn_error_t>

Change the value of a directory’s property.

• @a dir_baton specifies the directory whose property should change.
• @a name is the name of the property to change.
• @a value is the new (final) value of the property, or @c 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 @a scratch_pool.

close_directory: Option<unsafe extern "C" fn(dir_baton: *mut c_void, scratch_pool: *mut apr_pool_t) -> *mut svn_error_t>

We are done processing a subdirectory, whose baton is @a dir_baton (set by @c add_directory or @c 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 @a scratch_pool.

absent_directory: Option<unsafe extern "C" fn(path: *const c_char, parent_baton: *mut c_void, scratch_pool: *mut apr_pool_t) -> *mut svn_error_t>

In the directory represented by @a parent_baton, indicate that @a 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 @a scratch_pool.

add_file: Option<unsafe extern "C" fn(path: *const c_char, parent_baton: *mut c_void, copyfrom_path: *const c_char, copyfrom_revision: svn_revnum_t, result_pool: *mut apr_pool_t, file_baton: *mut *mut c_void) -> *mut svn_error_t>

We are going to add a new file at @a path, a child of the directory represented by @a parent_baton. The callback can store a baton for this new file in @a **file_baton; whatever value it stores there should be passed through to @c apply_textdelta or @c apply_textdelta_stream.

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

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

@note Because the editor driver could be employing the “postfix deltas” paradigm, @a 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 @a result_pool only for those batons. (Consider using a subpool of @a result_pool for scratch work, destroying the subpool before exiting this function’s implementation.)

open_file: Option<unsafe extern "C" fn(path: *const c_char, parent_baton: *mut c_void, base_revision: svn_revnum_t, result_pool: *mut apr_pool_t, file_baton: *mut *mut c_void) -> *mut svn_error_t>

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

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

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

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

apply_textdelta: Option<unsafe extern "C" fn(file_baton: *mut c_void, base_checksum: *const c_char, result_pool: *mut apr_pool_t, handler: *mut svn_txdelta_window_handler_t, handler_baton: *mut *mut c_void) -> *mut svn_error_t>

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

@a 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 @c add_file or @c open_file callback.

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

@a 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, @c apply_textdelta or the @a *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 @a base_checksum is neither NULL nor the hex MD5 checksum of the empty string).

change_file_prop: Option<unsafe extern "C" fn(file_baton: *mut c_void, name: *const c_char, value: *const svn_string_t, scratch_pool: *mut apr_pool_t) -> *mut svn_error_t>

Change the value of a file’s property.

• @a file_baton specifies the file whose property should change.
• @a name is the name of the property to change.
• @a value is the new (final) value of the property, or @c 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 @a scratch_pool.

close_file: Option<unsafe extern "C" fn(file_baton: *mut c_void, text_checksum: *const c_char, scratch_pool: *mut apr_pool_t) -> *mut svn_error_t>

We are done processing a file, whose baton is @a file_baton (set by @c add_file or @c open_file). We won’t be using the baton any more, so whatever resources it refers to may now be freed.

@a text_checksum is the hex MD5 digest for the fulltext that resulted from a delta application, see @c apply_textdelta and @c apply_textdelta_stream. 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, @a text_checksum is ignored.

Any temporary allocations may be performed in @a scratch_pool.

absent_file: Option<unsafe extern "C" fn(path: *const c_char, parent_baton: *mut c_void, scratch_pool: *mut apr_pool_t) -> *mut svn_error_t>

In the directory represented by @a parent_baton, indicate that @a 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 @a scratch_pool.

close_edit: Option<unsafe extern "C" fn(edit_baton: *mut c_void, scratch_pool: *mut apr_pool_t) -> *mut svn_error_t>

All delta processing is done. Call this, with the @a edit_baton for the entire edit.

Any temporary allocations may be performed in @a scratch_pool.

abort_edit: Option<unsafe extern "C" fn(edit_baton: *mut c_void, scratch_pool: *mut apr_pool_t) -> *mut svn_error_t>

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 @a scratch_pool.

apply_textdelta_stream: Option<unsafe extern "C" fn(editor: *const svn_delta_editor_t, file_baton: *mut c_void, base_checksum: *const c_char, open_func: svn_txdelta_stream_open_func_t, open_baton: *mut c_void, scratch_pool: *mut apr_pool_t) -> *mut svn_error_t>

Apply a text delta stream, yielding the new revision of a file. This callback operates on the passed-in @a editor instance.

@a 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 @c add_file or @c open_file callback.

@a open_func is a function that opens a #svn_txdelta_stream_t object. @a open_baton is provided by the caller.

@a 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, @c apply_textdelta_stream 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 @a base_checksum is neither NULL nor the hex MD5 checksum of the empty string).

Any temporary allocations may be performed in @a scratch_pool.

@since New in 1.10.

Trait Implementations

impl Clone for svn_delta_editor_t

fn clone(&self) -> svn_delta_editor_t

Returns a duplicate of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Debug for svn_delta_editor_t

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl Default for svn_delta_editor_t

fn default() -> svn_delta_editor_t

Returns the “default value” for a type.

impl Copy for svn_delta_editor_t