Function svn_repos_parse_dumpstream3 

pub unsafe extern "C" fn svn_repos_parse_dumpstream3(
    stream: *mut svn_stream_t,
    parse_fns: *const svn_repos_parse_fns3_t,
    parse_baton: *mut c_void,
    deltas_are_text: svn_boolean_t,
    cancel_func: svn_cancel_func_t,
    cancel_baton: *mut c_void,
    pool: *mut apr_pool_t,
) -> *mut svn_error_t

Read and parse dumpfile-formatted @a stream, calling callbacks in @a parse_fns/@a parse_baton, and using @a pool for allocations.

If @a deltas_are_text is @c TRUE, handle text-deltas with the @a set_fulltext callback. This is useful when manipulating a dump stream without loading it. Otherwise handle text-deltas with the @a apply_textdelta callback.

If @a cancel_func is not @c NULL, it is called periodically with @a cancel_baton as argument to see if the client wishes to cancel the dump.

This parser has built-in knowledge of the dumpfile format, but only in a limited sense:

• it recognizes the “magic” format-version header.

• it recognizes the UUID header.

• it recognizes revision and node records by looking for either a REVISION_NUMBER or NODE_PATH headers.

• it recognizes the CONTENT-LENGTH headers, so it knows if and how to suck up the content body.

• it knows how to parse a content body into two parts: props and text, and pass the pieces to the vtable.

This is enough knowledge to make it easy on vtable implementors, but still allow expansion of the format: most headers do not have to be handled explicitly.

[JAF] Wouldn’t it be more efficient to support a start/end rev

range here than only supporting it in receivers such as
svn_repos_get_fs_build_parser4()? This parser could then skip over
chunks of the input stream before the oldest required rev, and
could stop reading entirely after the youngest required rev.

@since New in 1.8.

@since Starting in 1.10, @a parse_fns may contain NULL pointers for those callbacks that the caller is not interested in.