Re: Outstanding Patches.

> +svn_stringbuf_t *
> +svn_wc__adm_empty_file (const svn_stringbuf_t *path,
> + apr_pool_t *pool)
> +{
> + svn_stringbuf_t *empty_file_path = svn_stringbuf_dup (path, pool);
> + svn_path_remove_component (empty_file_path, svn_path_local_style);
> + svn_path_add_component_nts (empty_file_path, SVN_WC_ADM_DIR_NAME,
> + svn_path_local_style);
> + svn_path_add_component_nts (empty_file_path, SVN_WC__ADM_EMPTY_FILE,
> + svn_path_local_style);
> + return empty_file_path;
> +}

It might be better to just use thing_path here, no?

Other than that, I have another idea. Right now diff handling is done
completely in the client. There is no svn_client_diff in libsvn_client.
Here's my thought: Make a svn_client_diff whose job is to return an
apr_hash_t (or something), mapping filenames to the the files they should be
diffed against.

This would provide two benefits that I can see:

1) Other clients would be able to just get a mapping to do the diff, instead of
duplicating all the recursiveness code, etc.

2) Performance-wise, this would allow you to load the entries file once per
directory, and check all of the entries with it to determine there addedness,
instead of re-loading the entries file for each call into
svn_wc_get_pristine_path. This probably doesn't make too much difference on
modern computers which will buffer the file contents anyway, but it is
conceptually cleaner.

What do you think? Are you up to a patch of this magnitude?

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Pilch-Bisson                    http://www.pilch-bisson.net
     "Historically speaking, the presences of wheels in Unix
     has never precluded their reinvention." - Larry Wall
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~