Community
Participate
Working Groups
When SVN patches contain new files, the new Apply Patch wizard is not letting you apply them. I assume this has something to do with the SVN Unified Diff format. Subclipse patches always have absolute path names because when we run the svn diff library code, the current working directory is not set to your project folder as it typically would be when you run the svn command line. That being said, even if I manually edit the patch to make all paths relative, it still will not allow me to add the new files. The same patch applies fine in Eclipse 3.1 and 3.0. This could be a very significant problem for SVN and Eclipse 3.2.
Created attachment 42358 [details] Sample SVN Patch Sample SVN patch with new and modified files.
This issue is a showstopper for Eclipse interoperability with other version control systems. I think, if it is possible, it is important to resolve it in 3.2 time frame.
I have debugged the code and see the problem. I just do not know the solution. org.eclipse.compare.internal.patch.Diff#getType returns whether the patch item is an Add, Change or Delete. It seems to base this on dates that were previously extracted from the diff header for each file. Subversion diffs do not put dates in the header. The way the code works, this treats every file as a Differencer.CHANGE. In the case of the file being an Add, this means that it thinks the workspace file is missing. I imagine that Deletes would have some similar problem. It seems like there has to be a better way to figure out if a patch item is an Add/Change or Delete.
and you are sure that applying this patch has worked in 3.1 or 3.0? I cannot remember that we have changed the way we recognize adds and deletes in any way since then. Bogdan, are you aware of any changes in that area?
Yes, I am sure. Besides that I regularly need to apply patches, I made sure to test this particlar patch. I used 3.0 for the test, but I am sure it works in 3.1 as well. I tried doing Annotate on the code last night. It looked like a lot of it had changed with the commit that added that feature so it was hard to tell if it had been there in a different form in the past. Subversion patches have never had dates in them though.
Is there anyway you could determine if a file is an add by looking at the first line after the two files? An add will always start with this @@ -0,0 I do not know if a modification could ever start like that. If it could, then it could maybe go a step further and see if the content of the patch was just a single contiguous block of adds. Alternatively, could the dialog itself just be made to have an option to force the addition of the new file? I can see where that would be hard if it really was not an Add and the local workspace file really was missing. It seems like improving the Add detection would be the best solution.
The problem here is caused by the new safe-guard code added to the Apply Patch wizard. But its root cause is that the CVS version of the unified diff format differs from Subversion's and the Apply Patch wizard is wired to go with the CVS version. GNU diff states that the beginning of a diff in unified format starts like this: --- from-file from-file-modification-time +++ to-file to-file-modification-time CVS diff produces files that adhere to this format. For new files, CVS returns --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ filename file_timestamp For this reason, the patcher looks out for /dev/null to detect a new addition. Subversion diff does not include dates and, more importantly, does not include the /dev/null for new file creation. Nothing wrong with that - the unified diff format is unclear on the exact format expected for new file creation. For 3.2 we redid a bunch of the Apply Patch wizard and introduced some checking code that prevented users from adding hunks that had problems with them. This is what is causing the problem for Subversion. Previously in 3.0 and 3.1, a newly added Subversion file would appear with an exclamation mark next to it (representing an error) - but the user could overwrite it and choose to apply it anyways. With the new code this is no longer possible. For new Subversion files, it turns out that the patcher is able to successfully apply the patch, but the Apply Patch wizard reports an error. The safest fix at this point is to remove the added error checks and allow users to apply diffs and hunks with errors. This is a safe route because we didn't touch any of the codethat does the actual patching - this has been well exercised prior to 3.2 and contains logic for dealing with failed patching attempts.
Created attachment 42482 [details] A patch for the Apply Patch Wizard - in unified diff format
McQ, can you approve this for RC6/7?
I applied your patch and can verify that it does seem to correct the problem. Thanks
+1
I have reviewed the patch. +1
let me know if I can apply the patch. I'm on the road tomorrow but should find some time in the evening...
Thanks Andre. John, can you have a look at the patch? That should give us enough +1's to release it.
patch applied in HEAD
Verified in I20060526-0010
