On Sat, 2004-05-01 at 09:33, jpieper@tigris.org wrote:
> Author: jpieper
> Date: Sat May 1 09:33:16 2004
> New Revision: 9592
>
> Modified:
> trunk/subversion/libsvn_client/blame.c
> trunk/subversion/libsvn_client/client.h
> trunk/subversion/libsvn_client/ra.c
> Log:
> Issue #1093: Update svn_client__prev_log_path to work with the current
> blame routine and refactor the existing blame code to use it.
Man, I am so happy you're working on this. :-)
> 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?
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?
---------------------------------------------------------------------
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:23:09 2004