Bug 17873 - Synchronize Comparison does poor job on .classpath files
Summary: Synchronize Comparison does poor job on .classpath files
Status: VERIFIED WONTFIX
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 2.0   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 2.0 F2   Edit
Assignee: Olivier Thomann CLA
QA Contact:
URL:
Whiteboard:
Keywords:
: 19072 (view as bug list)
Depends on:
Blocks:
 
Reported: 2002-05-26 12:02 EDT by Peter Burka CLA
Modified: 2002-06-05 10:09 EDT (History)
2 users (show)

See Also:


Attachments
.classpath file 1 (24.94 KB, text/plain)
2002-05-26 12:03 EDT, Peter Burka CLA
no flags Details
.classpath file 2 (24.94 KB, text/plain)
2002-05-26 12:03 EDT, Peter Burka CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Burka CLA 2002-05-26 12:02:39 EDT
Build F1

Whenever I change a project's Java build path and try to synchronize with CVS, 
the Synchronize view insists that the entire .classpath file has changed.

For some reason, it appears unable to find the individual differences in these 
files.

I'll attach two .classpath files which demonstrate this problem.
Comment 1 Peter Burka CLA 2002-05-26 12:03:47 EDT
Created attachment 1061 [details]
.classpath file 1
Comment 2 Peter Burka CLA 2002-05-26 12:03:57 EDT
Created attachment 1062 [details]
.classpath file 2
Comment 3 Kevin McGuire CLA 2002-05-27 12:12:29 EDT
Presumably what is happening is that the .classpath is being rewritten with 
identical contents. Since the timestamp on the file has changed, we believe its 
changed.  There is an option to do source level compare, which is slower, but 
will eliminate "false" changes ("Compare File Contents" from view dropdown).

For the .vcm_meta, we used to ensure we weren't rewritting identical content 
(its an easy hack, you just write to a buffer first and compare it to the file 
before writing). JDT could consider doing the same. I thought JDT was doing 
this already.

I am assuming this is what is going on (we haven't seen other reports of false 
changes).  If reporter checks to see if the timestamp on the file hasn't 
changed, then report it back to us.  For now, moving to JDT for comment and 
investigation of .classpath generation.
Comment 4 Kevin McGuire CLA 2002-05-27 12:34:54 EDT
Reporter has now explained to me that each line was shown as changed, which 
indicates EOL differences.

I've recommended that they convert their .classpath to text using the keyword 
substitution wizard.

Has JDT changed the EOL that they generate?  I seem to recall some discussion 
around this.  I assume this is in conjunction with 17564.

If this matches what's happened, this bug can presumably be closed, but JDT-
core should notify the dev mail list of the fact that people's .classpaths will 
need to be converted.
Comment 5 Philipe Mulet CLA 2002-05-27 13:07:53 EDT
.classpath EOLs are now platform dependent, and the file itself should be 
converted to text format.

This was in our build notes from F1 build:
================================
Eclipse Platform Build Notes 
Java Development Tooling Core
Eclipse SDK Build 20020521 - 21st May 2002 
Project org.eclipse.jdt.core v_249 - MILESTONE 6 (& F1) 
What's new in this drop
'.classpath' file is now written using platform line delimiters (used to be 
only using LFs). It is recommanded to convert it to 'text' format so as to 
avoid surfacing delimiter differences in between incompatible platforms. 
================================
Agreed that we should broadcast this louder.

Now, one more thing is that since last integration build, JDT/Core suggests 
that the .classpath file be tagged as source (through recommandation in 
plugin.xml), and the .classpath file should probably then get a marker if it 
does not match the recommanded mode. I have entered a defect for this one for 
all resources.
Comment 6 Olivier Thomann CLA 2002-06-03 14:16:17 EDT
Nothing to verify.
Comment 7 Olivier Thomann CLA 2002-06-03 14:16:31 EDT
Closed.
Comment 8 Dejan Glozic CLA 2002-06-05 10:09:15 EDT
*** Bug 19072 has been marked as a duplicate of this bug. ***