This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
There is a serious bug if a file is updated via patch from one revision to another and lines are added to the beginning of the target revision. Javacvs doesnt change the file content but the revision number. This can cause the losing of changes without realizing it! The following Exception occurs: java.lang.Exception: wrong parsing..a0 2 at org.netbeans.lib.cvsclient.util.BugLog.bug(BugLog.java:58) at org.netbeans.lib.cvsclient.file.WriteRcsDiffFilePreprocessor.copyTextFileToLocation(WriteRcsDiffFilePreprocessor.java:119) at org.netbeans.lib.cvsclient.file.DefaultFileHandler.writeAndPostProcessTextFile(DefaultFileHandler.java:326) at org.netbeans.lib.cvsclient.file.DefaultFileHandler.writeRcsDiffFile(DefaultFileHandler.java:262) at org.netbeans.lib.cvsclient.response.RcsDiffResponse.process(RcsDiffResponse.java:119) at org.netbeans.lib.cvsclient.Client.handleResponse(Client.java:436) at org.netbeans.lib.cvsclient.Client.processRequests(Client.java:397) at org.netbeans.lib.cvsclient.command.update.UpdateCommand.execute(UpdateCommand.java:282) at org.netbeans.lib.cvsclient.Client.executeCommand(Client.java:480) at org.netbeans.modules.javacvs.commands.FileSystemCommand.run(FileSystemCommand.java:443) at java.lang.Thread.run(Thread.java:536) The bug is caused by line 112 in WriteRcsDiffFilePreprocessor: if (startLine > 0 && count > 0) { In my opinion this should be: if (startLine >= 0 && count > 0) { due to startLine == 0 is a legal value. This fixes the bug but please check for unintentional side-effects. Additionally the handling of Exceptions like this should be changed in that way that the revision number isnt changed and the user should be informed of an error.
What do you think Martin ?
Maybe. I'll check it next week. I'm currently busy with issue #27102.
Changing to DEFECT (so that it appears in queries and because we're permitted to fix only defects into 3.5 in this stage). Thanks for the patch, I'll verify it...
The patch seems to be correct. I've verified it on a simple testcase. I've also added an exception, that is thrown in case the parsing process gets wrong. This prevent creation of a corrupted file. Fixed in the main trunk: /cvs/javacvs/libsrc/org/netbeans/lib/cvsclient/file/WriteRcsDiffFilePreprocessor.java,v <-- WriteRcsDiffFilePreprocessor.java new revision: 1.9; previous revision: 1.8 I'll merge it into release35 after verification in dev builds. The only strange thing is, that there is not handled 'c' in the diff. Only 'a' and 'd'. It seems, that it does not matter, since cvs.exe server sends changes as 'd' followed by 'a'. But as soon as the server decides to send 'c' instead, the update will break. Milos, don't you know whether it's specified somewhere that the 'c' can not be sent?
Setting the Target Milestone to 4.0 (where it's currently fixed).
As to the problem of 'c': I've read carefully the documentation to Rcs-diff response and concluded, that 'c' is not sent due to 'diff -n', which returns RCS-format diffs. RCS-format diffs use only 'a' and 'd' by definition.
Can you please herkrath verify the fix in development builds ? Thanks !
Looks good! But you should take into account to put this fix into 3.5. We already had some problems due to this bug since a long time ago. We just couldn't find out what the reason was and I didn't want to report a bug like "CVS doesn't work". I guess we were not the only ones.
O.K., thanks Herkrath. Since this has been verified in the main trunk, I'm going to merge it into release35 branch. Here's the diff, that is going to be merged: http://www.netbeans.org/source/browse/javacvs/libsrc/org/netbeans/lib/cvsclient/file/WriteRcsDiffFilePreprocessor.java.diff?r1=1.8&r2=1.9
This fix is merged into release35 branch: /cvs/javacvs/libsrc/org/netbeans/lib/cvsclient/file/WriteRcsDiffFilePreprocessor.java,v <-- WriteRcsDiffFilePreprocessor.java new revision: 1.8.2.1; previous revision: 1.8