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

Re: [PATCH] Disambiguate (de)translation; followup.

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: 2005-11-19 14:40:09 CET

Erik Huelsmann wrote:
>
>>Also, you updated all the callers, but there don't appear to _be_ any
>>callers that pass these flags: do we really need them? Perhaps better
>>as a separate patch?
>
> Yes, we need them. What you found is a flaw in my patch. I should have
> updated svn_wc_translated_file (). Julian commented that I discarded
> an argument which I shouldn't have. It needs this patch:
>
> @@ -114,7 +114,10 @@
> /* we discard the force_repair flag,
> because we know what to do ourselves now... but is it acceptable?! */
> return svn_wc_translated_file2 (xlated_p, vfile, vfile, adm_access,
> - SVN_WC_TRANSLATE_TO_NF, pool);
> + SVN_WC_TRANSLATE_TO_NF
> + | (force_repair
> + ? SVN_WC_TRANSLATE_FORCE_EOL_REPAIR
> + : SVN_WC_TRANSLATE_NO_EOL_REPAIR), pool);
> }

I don't think that's right. Here's what the function used to do:

> if (style == svn_subst_eol_style_fixed)
> {
> SVN_ERR (svn_subst_copy_and_translate3 (vfile,
> tmp_vfile,
> eol,
> TRUE,
> keywords,
> FALSE,
> special,
> pool));
> }
> else if (style == svn_subst_eol_style_native)
> {
> SVN_ERR (svn_subst_copy_and_translate3 (vfile,
> tmp_vfile,
> SVN_WC__DEFAULT_EOL_MARKER,
> force_repair,
> keywords,
> FALSE,
> special,
> pool));
> }
> else if (style == svn_subst_eol_style_none)
> {
> SVN_ERR (svn_subst_copy_and_translate3 (vfile,
> tmp_vfile,
> NULL,
> force_repair,
> keywords,
> FALSE,
> special,
> pool));
> }

So, only repair from "native" and "none" was controlled by the option, but
repair from "fixed" was always done.

Note also that this is an implementation of a deprecated funtion. It doesn't
need to use public functionality, it could use private functionality shared
between svn_wc_translated_file() and svn_wc_translated_file2(). So this
doesn't mean that those two flags are required in the public interface.

- Julian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Nov 19 14:41:00 2005

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.