Bug 81637 - CVS compare uses wrong character encoding
Summary: CVS compare uses wrong character encoding
Status: RESOLVED DUPLICATE of bug 72995
Alias: None
Product: Platform
Classification: Eclipse Project
Component: Compare (show other bugs)
Version: 3.1   Edit
Hardware: Macintosh Mac OS X - Carbon (unsup.)
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Platform-Compare-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-12-20 04:01 EST by Stefan Tannenbaum CLA
Modified: 2005-01-06 12:06 EST (History)
1 user (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Stefan Tannenbaum CLA 2004-12-20 04:01:55 EST 
I frequently compare local sourcefiles with the latest versions from our CVS repository, mostly by 
double clikcing a conflict in the synchronize perspective.

The compare editor then loads the local file using the specified character encoding for this file (in my 
case latin1) and the remote file using the default character encoding of the workbench (in my case utf
-8). The result is a scrambled remote file and a lot of false positive changes.

The remote file should always be read in the same character encoding as the local file.

Setting the default character encoding of the workbench to latin1 has helped for my project, but this 
was not obvious and took me some weeks to discover. It is also a problem if two different encodings 
are used frequently.
Comment 1 Andre Weinand CLA 2005-01-06 12:06:20 EST 

*** This bug has been marked as a duplicate of 72995 ***