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

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

From: <kfogel_at_collab.net>
Date: 2004-10-04 16:39:04 CEST

"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

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
Received on Mon Oct 4 18:26:37 2004

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.