You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Jim Blandy <ji...@savonarola.red-bean.com> on 2000/10/09 04:33:14 UTC
Need doc fix?
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);
Re: Need doc fix?
Posted by Karl Fogel <kf...@galois.collab.net>.
Jim Blandy <ji...@savonarola.red-bean.com> writes:
> You're probably less flaky than I am,
Doubtful.
> but I've had bad experiences
> with "Yes, I'll fix it soon."
Not doubtful. :-)
> Either I keep everything up to date
> always, or things just deteriorate over time. Just my two cents.
Yeah, I think I'll try to leave less unfinished business around the
code, and do things in complete chunks instead. Better for all of us.
-K
> Karl Fogel <kf...@galois.collab.net> writes:
>
> > 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 <ji...@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);
Re: Need doc fix?
Posted by Jim Blandy <ji...@savonarola.red-bean.com>.
You're probably less flaky than I am, but I've had bad experiences
with "Yes, I'll fix it soon." Either I keep everything up to date
always, or things just deteriorate over time. Just my two cents.
Karl Fogel <kf...@galois.collab.net> writes:
> 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 <ji...@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);
Re: Need doc fix?
Posted by Karl Fogel <kf...@galois.collab.net>.
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 <ji...@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);