Bugzilla – Full Text Bug Listing
| Summary: | [Patch] Apply Patch should be able to handle patches generated by diff | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Nick Boldt <nboldt> | ||||
| Component: | Compare | Assignee: | Platform Team Inbox <platform-team-inbox> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | gheorghe, ns03ja | ||||
| Version: | 3.2 | Keywords: | helpwanted | ||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Linux | ||||||
| Whiteboard: | stalebug | ||||||
| Attachments: |
|
||||||
|
Description
Nick Boldt
Created attachment 50526 [details]
patch to update EMFT site to Phoenix skin
The attached patch is the one used in the above steps to reproduce, giving an example of a patch containing new files which Eclipse does not create when applied.
Which build are you using? (Help->About Eclipse SDK, build id) Eclipse 3.2 GM (eg., org.eclipse.platform_3.2.0.v20060609m-AgOexn6hlEUsvBO). I tried out your scenario and I was able to reproduce what you saw (using the version on 2006-09-19). However, I also looked at your patch and the format is wrong for the Apply Wizard to detect the new files (which is why _projectCommon.php doesn't show up). Did you create this patch from within Eclipse? I tried using the Create Patch wizard to pick up a new file and it worked no problem. Finally, I should mention that we're planning to put in some support for manual merging of hunks that can't be applied into 3.3. This means that if you send a patch of a file that isn't in CVS to someone, he will be able to merge your changes in to any changes he has made, as opposed to the Apply Patch Wizard completely rewriting his version of the file. (Although life would be much easier for you if you would just commit the file...) No, that patch was created with a 'cvs diff -u' followed by a 'diff -u /dev/null newfile' for each of the new files, as CVS's diff does not handle new files. I replaced each of the /dev/null entries with the file that was to be patched as Eclipse can't handle diffs against /dev/null either. The standard 'patch' utility has no problems with the above use case and it is not particularly uncommon to add new files with a patch. Eclipse should be compatible with standard patches and not just with itself. OK - I see what you did now, althought I'm not sure why you didn't use the Eclipse Create Patch wizard, which would have picked up the new files for you. In either case, it is true that the Apply Patch wizard cannot handle patches created using the command line diff tool. We unfortunately do not have the manpower available to currently address this deficiency. If this is an important feature to you, we will happily accept a patch and test case. In addition, the Apply Patch Wizard should also be able to work with patches that contain mixed CVS diffs along with diff tool diffs. As a corollary to this, the universal diffs generated by cvs on Solaris (and probably other platforms) contain truly empty lines whereas the blank lines created by Eclipse's Create Patch wizard include a single space. Eclipse sees the CVS patches as malformed and cannot apply them. If I edit the patch so that each blank line has one space, then the patch works. Here's an example (not an actual patch, but it gives you the idea): Index: helloWorld.txt =================================================================== RCS file: /project/helloWorld.txt,v retrieving revision 1.2 diff -u -r1.2 helloWorld.txt --- helloWorld.txt 10 Oct 2006 21:17:32 -0000 1.2 +++ helloWorld.txt 19 Oct 2006 16:11:50 -0000 @@ -21,10 +21,9 @@ Some text here. Some more text preceding a blank line. -The preceding line is blank when created with CVS diff. +The preceding line contains a single space if this patch is created with Eclipse Create Patch. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it and remove the stalebug whiteboard tag. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. |