Peter N. Lundblad wrote:
> I'm changing svn_diff_file_output_unified to taken an header_encoding
> argument. So the problem is more like, if you say
> svn diff > patchfile.diff
> you could expect the headders to be in the native encoding (or the file's
> encoding if that's known), but if you do
> svn diff | more
> you probably want headers to be in the console encoding. But then the
> encoding is inconsistent wit the file's encoding (unless it is the console
> codepage, which seems uncommon if it is the old DOS 8bit encodings at
> least). A similar problem should exist for all our commands on Windows.
For the first pass, I'd translate everything to the console
code page.
If we want to get smarter, we could translate to code page if
stdout is a console or a pipe, but translate to the file encoding
(when known) if the output is a file.
Eventually, because I don't think the pipe case is deterministic
(i.e., some applications of pipes will want one thing while
others will want the other) I suspect we need a command line
flag.
I would think that unix has the same problem.
You terminal expects output in one encoding (specified by LANG
probably), and the file may have a different encoding.
Does unix not have this problem?
(Windows is more complicated by the OEM garbage... but other than
that, I don't think the problem is windows specific?)
Thanks,
Joseph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon May 2 19:10:38 2005