[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] allow svnsync to translate non-UTF-8 log messages to UTF-8 (v. 3)

From: Julian Foad <julian.foad_at_wandisco.com>
Date: Fri, 14 Jan 2011 17:31:50 +0000

On Fri, 2011-01-14 at 09:16 -0800, Danny Trebbien wrote:
> >>> - SVN_ERR(normalize_string(&value, &was_normalized, pool));
> >>> + SVN_ERR(normalize_string(&value, &was_normalized, eb->prop_encoding,
> >>> + pool, pool));
> >>> if (was_normalized)
> >>> - (*(eb->normalized_node_props_counter))++;
> >>> + (*(eb->le_normalized_node_props_counter))++;
> >>> }
> >>
> >> This kind of code can be simplified (removing one level of indirection)
> >> by making the baton hold the actual counter instead of a pointer to it.
> >
> > Okay.
>
> Actually, I take that back. The pointer to the count comes from the
> "public API" function svnsync_get_sync_editor(). I don't think that
> this indirection can be removed without adding another API function to
> retrieve the count. Something like:
>
> int
> svnsync_get_edit_baton_normalization_count(void *edit_baton)
> {
> return ((edit_baton_t*) edit_baton)->normalized_node_props_count;
> }

Oh... I was assuming there was some bit of code here in this file that
would be called at the end of all the processing, that could copy the
final count from the baton to the place where the caller wanted it. If
that's not the case - if there's no place here where we could do that -
then I suggest we leave it as it is. This was just a drive-by comment
and not a good reason to change the API.

- Julian

> Maybe this change can be done in another patch as the patch is getting
> large again.
Received on 2011-01-14 18:32:36 CET

This is an archived mail posted to the Subversion Dev mailing list.