pedit and --encoding (issue (issue #2063)

["Peter N. Lundblad" <pe...@famlundblad.se>]

Hi,

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).

Regards,
//Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: pedit and --encoding (issue (issue #2063)

["Peter N. Lundblad" <pe...@famlundblad.se>]

On Mon, 4 Oct 2004 kfogel@collab.net wrote:

> "Peter N. Lundblad" <pe...@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

Re: pedit and --encoding (issue (issue #2063)

[kf...@collab.net]

"Peter N. Lundblad" <pe...@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"?

Whether it works right now is a different question, I'm just talking
about what the option *should* mean.



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org