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.
Another CVS problem, let's hope we can resolve this as quickly as the last two I reported. I'm using 3.5RC1, connected to a CVS repository using the built in java client. I've checked all of the CVS related files to make sure that nothing is amiss there. The problem: After committing, my local file appears as I left it while the file in the cvs repository has extra characters appended at the end of the file. An example: immediately after the brace denoting the end of my class, the following characters appear: ates = new Vector () ;. At line 21 in my file, I have the line: private Vector m_possibleCaseStartDates = new Vector () ;. This is the only line that could possibly match the text string inserted by the commit that was contained in this class. The text string appended for this class appears to be the same each time I perform a commit. This happens when both a single file or multiple files are committed, although the problem tends to manifest in the same file/group of files. my vcs commands (from the explorer runtime tab) are: status commit -m "" my cvslog.in and cvslog.out are attached. The file which continually gives problems is ContingencyBasedSchedule.java.
Created attachment 10206 [details] mycvslog.in
Created attachment 10207 [details] mycvslog.out
This seems to be a severe error. But it's strange that it doesn't seem to happen for others. If this is a real bug, then it happens rarely. > let's hope we can resolve this as quickly as the last two I > reported. Hmm, I don't know yet where the problem might be. From the loggs I do not find much, the content of the sent file is not written there. What CVS server do you use? How did you verify, that the file is corrupted in the repository? Did you do a checkout? In such case the bug might be in checkout.
I tried to reproduce this problem, but I wasn't successful. If it's not confidential, can you please attach the file that cause these problems?
I'm using the most recent version of cvs distributed with debian woody. cvs --version returns the following: Concurrent Versions System (CVS) 1.11.1p1 (client/server) Copyright (c) 1989-2001 Brian Berliner, david d `zoo' zuhn, Jeff Polk, and other authors I verified the file was corrupt by SSH'ing into the cvs repository and viewing the file there (before doing a checkout). It may be worth mentioning that I have a second mounted local repository in netbeans which I'm using as my output directory.
Created attachment 10213 [details] The file that causes this problem
Thanks Jason, I was able to reproduce it with your file. However the reproduction was successful after I removed the last newline from your file (it seems, that the attached file does not end with newline, but it was saved with one at the end). So it looks like the fast solution for you can be to add a newline at the end of the file. However this problem needs to be explored and fixed anyway. Strange thing is, that when I create a new file and remove the last newline, it behave correctly. I'm going to explore the problem...
The problem was found and is fixed in the main trunk: /cvs/javacvs/libsrc/org/netbeans/lib/cvsclient/file/DefaultTransmitTextFilePreprocessor.java,v <-- DefaultTransmitTextFilePreprocessor.java new revision: 1.8; previous revision: 1.7 The bug happens when the file does not end with a newline character and the file is longer than 32768 bytes. In this case a chunk of text from the middle of the file is appended to the end of the file. Also this can happen only on Windows (or other systems, that have newline different from '\n').
Created attachment 10217 [details] Attaching the whole compiled cvs library with the applied fix. It seems that this library can not be patched. Put into <NB-install>/modules/ext/ instead of the original cvslib.jar.
Created attachment 10218 [details] The textual diff of the fix.
I'll check it tomorrow on WinXP...
Dan, please do not change Target Milestones. Reverting back to 4.0.
I can't reproduce the bad behaviour on Nevada RC2 #030502 even without the Martin's patch:-/ keeping trying to verify on NB35
OK the FIX is good. I couldn't reproduce it 'cause I didn't remove the last new line:-( So I reproduce the bad behavior on Nevada RC2 and on NB35rc1. I can comfirm that Martin's patch is fixing the problem. (only small details: there are probably forgotten debug messages)
Code reviewed without objections.
approved for 3.5
Thanks for the verification, review and approval. The bug is fixed in the release35 branch: /cvs/javacvs/libsrc/org/netbeans/lib/cvsclient/file/DefaultTransmitTextFilePreprocessor.java,v <-- DefaultTransmitTextFilePreprocessor.java new revision: 1.7.2.1; previous revision: 1.7
*** Issue 33623 has been marked as a duplicate of this issue. ***
I checked this fix against the original offending file. The problem no longer occurs.