Community
Participate
Working Groups
Build: Eclipse 2.0 The AbstractImageBuilder together with the IncrementalImageBuilder deletes and creates a class file rather than overwriting the existing one. This causes one extra OS call per class file. It also makes it hard for VCMs which track changes in the filesystem to maintain history (I'm not sure this always makes sense for class files... but it could).
Created attachment 1699 [details] A possible fix in Eclipse patch format. (patch.txt)
See also http://bugs.eclipse.org/bugs/show_bug.cgi?id=20036
Thanks Jed... Rearranged the writeClassFile code so the IncrementalImageBuilder can control how the bytes are written. Your change removed the delete but added an exists check for the batch builder.
excellent. glad you caught the stuff i missed.
Just thought of something... What if the class files get marked read-only? (VCMs like to futz the read-only bit) Then the setContents call will fail, this could potentially be very unhappy.
But deleting them first is just as unhappy. 'We' control the class files... if they get tagged as read-only then that's a bug in the VCM which they would have to 'fix'. Ok?
No, IFile.delete happily deletes read-only files (like a fool). This means that IFile.delete(...) IFile.create(...) has different behaviour that IFile.setContents(...) when read-only files are introduced into the mix.
Fine but I still thinks its a VCM bug for them to tag class files which are not under version control as read-only.
Actually I just checked with DJ and delete does whatever the platform does... which on Windows means it will fail if the file is tagged read-only. I think this change will give us the same behavior as we had before...
I agree with marking this fixed, as VCMs shouldn't be so dumb as to try an version control derived files. However, two more points: 1. Relying on platform specific implementations sounds bug prone. 2. I just stepped through the code, and Windows lets you delete read-only files. I will notify DJ of this behaviour.
Just came across this PR and noticed that the patch file looks like it's removing and re-adding the whole contents of the affected files. How big was the actual change? Could indicate a bug in compare.
I don't think its a bug in Compare: patch files are generated by CVS; the Compare plugin only applies the patch.
Andre is correct, we call out to the CVS server to generate them. I haven't seen this -- I would need to know the steps taken to produce it. Its possible there was an EOL issue so all lines looked different to the diff? Other than asking the server to generate them, there's not much that we do that's interesting here.
Verified by stepping through the code.
Verified.
Verified in 2.1 M1
