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.
We've had this problem several time in the past and recently. Basically when one person is working on version 1.1 of a file, another person checked in to make it version 1.2. After the first person made changes to version 1.1, he/she tried to check in but failed. He/She then ran a CVS Update, then checked in the file to make it version 1.3. Ever now and then, version 1.3 would overwrite whatever the other person did in version 1.2. After doing some research, I found out that the problem was due to the fact that that was a failure in the CVS Update command but was ignored/not reported. For example, if the file name is File1.java, after running the CVS Update command, I would still have a file named .#File1.java.x.x in the directory. In the CVS/Entries file, File1.java has been updated version 1.2 but the content of my local copy is still 1.1 plus the changes I made. Thus by checking it, I overwrote the changes made by the previous revision. Will the problem be avoided if Netbeans changes the version number in the CVS/Entries file after it updates the file to be checked in later? Even if Netbeans failed to report or update the file, the version number in CVS/Entries will not be changed, thus preventing me from checking it in.
Are you using the built-in CVS client? If not, what command-line CVS client do you have installed? Since I doubt the the cvs.exe from cvshome.org suffers from problems like this, it is likely a bug in our built-in client implementation. Moving to javacvs module. We need to at least assure that the version number in Entries is changed only after successful update of the file.
I'm acutally using cvs.exe (version 1.11.9) from cvshome.org. The problem is really bad. It seemed to happen more with Netbeans 3.6. When I do update right now, I have to run cvs.exe from the command line to be sure that I don't mess up other people's changes again. With older versions of Netbeans (3.5, 3.4), I used to get errors when trying to update a File that is currently open in the Editor(although it should not be doing that). Could this be the same problem but not reported in Netbeans 3.6. I've always been a user/supporter for Netbeans despite the fact that some of my coworkers have moved to Eclipse. But this problem is really getting on to my nerve right now. Everything we do is based on CVS and I can't trust doing it with Netbeans anymore. I hope the problem can be addressed in the near future.
Well, I'm a little confused. You're using cvs.exe version 1.11.9 with NetBeans. And when you do update in NetBeans, it does not update your files properly. But when you do update (with the same cvs.exe I suppose) on command-line, the files are updated O.K. This is very strange, because all that NetBeans do is that they execute cvs update with some arguments. cvs.exe is doing the rest, including updates of CVS/Entries. Can you please find the execution string of update command that is constructed by NetBeans (you can find it in Runtime under "VCS Commands" node) and compare it's execution to when you run it manually? In the properties of "UPDATE_CMD" you'll find the execution string. Please cd into the same folder and copy the command (from cvs.exe ... , you might have to remove some extra backslashes). Then compare it's result with how do you run cvs update. Can you find what is causing the difference? Also, do you have some .cvsrc file? I've checked the code in our built-in client and it's apparent that CVS/Entries are not changed before the updated file is successfully written. Therefore it should behave correctly.
Well, to be honest I would say I sometimes face similar problems. I always use Built-in Client for nb_all updates but it happens for almost every build that some files are not updated inspite of "Update command finished." message in status bar. So, my advice for reproduction is: 1. Checkout standard_nowww from cvs.netbeans.org. 2. Wait one week. 3. Use Built-in Client to update all modules to current BLD2004... tag. 4. Checkout the same sources to another dir and compare the contents.
Adding INCOMPLETE keyword until we get comparison of the behavior of cvs.exe executed from NetBeans and executed manually on command-line. Jiri, the uncomplete update that you describe is likely a problem in the javacvs library and it is a different problem from this (did you try update with command-line client?)
Martin, I've tried to reproduce the problem a couple of times with no avail. However, this did happen several times to us and I believe I understand CVS well enough (just about) to know that I or my team didn't do anything wrong to make the overwrite happen. What I'm suspecting (this is only a theory) is that Netbeans probably ignored errors when running the cvs.exe update command. As a mentioned earlier, I've had problems in the past with Netbeans locking a file being edited. I discovered it when I tried to run CVS update on the file because I noticed there was a new revision. Netbeans gave an error indicating it was unabled to overwrite the current file. The problem showed up several times while I was using Netbeans 3.5.1. I hasn't shown up in Netbeans 3.6, but could it be that the error was somehow ignored? By running cvs.exe, I can be sure that I isolated the problem. From past experience, I know that cvs.exe would raise an error when it fails to overwrite a file. Since the problem doesn't occur all the time, I can't say that by running cvs.exe I will eliminate the problem. If the problem still happens with cvs.exe alone, I know it's no a problem of cvs.exe. However, I have never had this problem in the past while working directly with cvs.exe.
> What I'm suspecting (this is only a theory) is that Netbeans > probably ignored errors when running the cvs.exe update command. This is possible. The error reporting was actually improved in 4.0. There is a special component in Output into which the error output is printed whenever some command fails. However, the fact the NetBeans ignored some error output does not tell us how it happened that the content of the sources didn't match with CVS/Entries. NetBeans do not care about CVS/Entries when command-line client is used. So it's up to cvs.exe to manage that. > I've had problems in the past with Netbeans locking a file being > edited. This should be already solved in NetBeans 3.6. Since you mentioned this, I've recalled issue #36113. It is fixed in 3.6, but in 3.5 it was possible to encounter a data loss when you had a modified file in NetBeans and executed update. 3.6 (and 4.0) should treat it correctly, however. If we trust that cvs.exe alone does not make an inconsistent state, it must have been some interaction with running update and modified buffers in NetBeans. Do you think that it's possible that you have modified some files right before running Update in NetBeans? Also, did you edit Java files, or other types of files? If the modified file would not be saved for some reason before Update was executed, it could lead to this inconsistency (updated file is later overwritten by the modified buffer, which deletes all changes that were done by the other user). If you would encounter an inability to overwrite the current file by cvs.exe in 3.6, it would mean, that issue #36113 is still not fully fixed. But I did not have a problem with that so far. Jiri, did you modify some files before running update?
> Did you try update with command-line client ? No, because for some reason it takes twice more time. But on the other hand, maybe it's why some directories were not updated ... ! :-? > Did you modify some files before running update ? Of course not. The only modifications I did were immediatelly checked in and are always located in module I update separately.
The update works correctly for me, I'm not able to reproduce it. We would need some reproducible steps. If you encounter this problem again, please reopen, provide any error messages you get and steps how it happened and how we can reproduce it. Thanks.
Verified.