On Mon, 4 Oct 2004 kfogel@collab.net wrote:
> "Peter N. Lundblad" <peter@famlundblad.se> writes:
> > While working on issue 2063, I found a strange little thing. The problem
> > I'm trying to solve is that we don't translate the property to the native
> > eol-style before editing, but we just recode the string from UTF8. When we
> > read the file back, we do both things, *but*, the propedit command has an
> > --encoding option and when we translate to UTF-8, we take that option into
> > account. Note that we don't do that when encoding from UTF8. I don't
> > understand why we have --encoding on propedit (when would it be useful?)
> > and it obviously doesn't work currently. I'd like to get rid of it, but
> > then someone will start talking about API compatibility:-(
> >
> > Anyone has an idea why we have --encoding on this command? And would it be
> > possible to remove it? It obviously doesn't work currently. Note that the
> > commit command has an --encoding option but doesn't take it into account
> > when invoking the editor (it is used by the -F option I suppose).
>
> Conceptually, wouldn't --encoding=FOO with 'propedit' mean "The tmp
> file saved is in encoding FOO, so Subversion should translate it to
> UTF8"?
>
And: save the file in encoding FOO before editing. That's what doesn't
happen today AFAICT. What I didn't like is that it isn't consistent with
the commit log editing, where --encoding is only used with the -F option.
We discussed on irc yesterday and concluded that we need to fix so that
--encoding works both ways. The inconsistency is another matter that needs
separate discussion, since it also adds another meaning to the
log-encoding config option (or not, depending on what we do).
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Oct 4 22:01:15 2004