Yes, I agree -- this part of the code is still under development,
however, and though Ben and I were collaborating on it to some degree,
I had to go out of town for a few days. That's why it's languished in
this half-documented state.
However, there should be some indication of the fact that it's
incomplete (even when time is tight, as you say).
The TOK argument may go away tomorrow, though, so it'll get fixed
soonly.
Jim Blandy <jimb@savonarola.red-bean.com> writes:
> It looks like the description for this function and its prototype are
> way out of sync. There's no explanation for TOK, and mysterious
> references to CLOSE_COMMIT_FN and CLOSE_COMMIT_BATON.
>
> I think it's pretty important to keep the docs up to date, even when
> time is tight.
>
>
> /* Do a depth-first crawl of the local changes in a working copy,
> beginning at ROOT_DIRECTORY (absolute path). Communicate all local
> changes (both textual and tree) to the supplied EDIT_FNS object
> (coupled with the supplied EDIT_BATON).
>
> (Presumably, the client library will someday grab EDIT_FNS and
> EDIT_BATON from libsvn_ra, and then pass it to this routine. This
> is how local changes in the working copy are ultimately translated
> into network requests.)
>
> A function and baton for completing this commit must be set in
> *CLOSE_COMMIT_FN and *CLOSE_COMMIT_BATON, respectively. These are
> not so much for the caller's sake as for close_edit() in the
> editor, and they should be set before close_edit() is called. See
> svn_ra_get_commit_editor() for an example of how they might be
> obtained.
> */
> svn_error_t *
> svn_wc_crawl_local_mods (svn_string_t *root_directory,
> svn_delta_edit_fns_t *edit_fns,
> void *edit_baton,
> svn_string_t *tok,
> apr_pool_t *pool);
Received on Sat Oct 21 14:36:10 2006