Ben Collins-Sussman wrote:
> On Sat, 2004-05-01 at 09:33, jpieper@tigris.org wrote:
> > Modified: trunk/subversion/libsvn_client/client.h
> > ==============================================================================
> > --- trunk/subversion/libsvn_client/client.h (original)
> > +++ trunk/subversion/libsvn_client/client.h Sat May 1 09:33:16 2004
> > @@ -98,6 +98,8 @@
> > particular resource has undergone when performing an RA->get_logs()
> > operation on that resource. */
> > svn_error_t *svn_client__prev_log_path (const char **prev_path_p,
> > + char *action_p,
> > + svn_revnum_t *copyfrom_rev_p,
> > apr_hash_t *changed_paths,
> > const char *path,
> > svn_node_kind_t kind,
>
> Would you mind documenting the two new variables?
Of course, I meant to do that, but the desire got misplaced in between
switching to the header file.
> Also, I have a meta-worry:
>
> If you read the log history for blame.c, there have been some bugfixes
> to its core logic, but these happened *after* cmpilato branched the code
> into his svn_client__prev_log_path() patch. I can't remember the
> details of the fixes, but I'm concerned that blame.c has now regressed:
> it's now using factorized code, but the factorized code is lacking the
> bugfixes.
>
> So that's the next step: can you do a bit of research, and make sure
> svn_client__prev_log_path is just as robust as the blame code you just
> deleted?
I did do that research, and adding those two extra parameters was the
only thing I could find that affected prev_log_path. The only big
bugfix between November and now to log_message_receiver was in part
helped by cmpilato, and seemed to be included in prev_log_path
already.
-Josh
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon May 3 17:51:37 2004