I will mention that these path-based APIs were due to be deprecated by
1.7. Thus, this revision is a lot of churn on to-be-obsolete stuff. I
do understand that this kind of change can simplify higher-level bits,
and my fault for not making this clear.
Hmm. Might be proper to just mark those functions as deprecated, even
tho they're internal. Will think on that.
On Thu, Sep 10, 2009 at 19:04, Bert Huijben <rhuijben_at_sharpsvn.net> wrote:
> +++ trunk/subversion/libsvn_wc/adm_ops.c Thu Sep 10 16:04:56 2009 (r39230)
> @@ -2488,17 +2506,42 @@ svn_wc_get_pristine_copy_path(const char
> const char **pristine_path,
> apr_pool_t *pool)
> - *pristine_path = svn_wc__text_base_path(path, FALSE, pool);
> + svn_wc_context_t *wc_ctx;
> + const char *local_abspath;
> + SVN_ERR(svn_wc_context_create(&wc_ctx, NULL, pool, pool));
> + SVN_ERR(svn_dirent_get_absolute(&local_abspath, path, pool));
> + SVN_ERR(svn_wc__text_base_path(pristine_path, wc_ctx->db, local_abspath,
> + FALSE, pool));
> return SVN_NO_ERROR;
It would be better, I think to just create a DB rather than a WC_CTX.
And the ctx should be destroyed.
svn_wc_get_pristine_copy_path() should be moved to deprecated.c, too.
(not your fault, but seeing this now...)
> +++ trunk/subversion/libsvn_wc/copy.c Thu Sep 10 16:04:56 2009 (r39230)
> @@ -560,8 +561,8 @@ copy_file_administratively(svn_wc_contex
> - SVN_ERR(svn_wc_get_pristine_contents(&base_contents, src_abspath,
> - pool, pool));
> + SVN_ERR(svn_wc_get_pristine_contents2(&base_contents, wc_ctx, src_abspath,
> + pool, pool));
Shouldn't this be the internal version? svn_wc__get_pristine_contents() ?
Actually, I just thought of something. We had issues in FS with two
functions whose name only varied by that underscore. Massive
confusion, leading to link/bind errors and stuff. So... maybe
Received on 2009-09-12 10:34:57 CEST