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.
Summary: | [50cat] CVS update/commit is severely broken | ||
---|---|---|---|
Product: | versioncontrol | Reporter: | misterm <misterm> |
Component: | CVS library | Assignee: | issues@versioncontrol <issues> |
Status: | RESOLVED FIXED | ||
Severity: | blocker | CC: | jglick, tstupka, tzezula |
Priority: | P1 | ||
Version: | 5.x | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Issue Type: | DEFECT | Exception Reporter: | |
Bug Depends on: | 73181 | ||
Bug Blocks: | |||
Attachments: |
CVS log input file
CVS log output file |
Description
misterm
2006-01-17 13:19:09 UTC
Could you be more descriptive please? What have happened, silent commit failure? Any messages from output window or C/S protocol log (-J-DcvsClientLog)? Silent commit failure and update working as clean copy, with no reason. No messages were displayed in the output window. The versioning window showed no modified file after the commit operation. Please attach cvs log, thanks. (-J-DcvsClientLog=/tmp/cvs-lib) Do you remember your "commited" files content before the like-clean-update? (looks like Revert Modifications action was used... :-() > Please attach cvs log, thanks. (-J-DcvsClientLog=/tmp/cvs-lib)
I cannot reproduce the issue, but it seems like one that I've seen before RC1.
I remember developers thought there was a problem with CVS/Entries.
It happened again. CVS/Entries file for the file contained: /LayoutDefinitionReader.java/1.1.2.12/Mon Feb 20 18:13:44 2006//TIMPORTACAO_COTACAO Then I ran update and it still contained: /LayoutDefinitionReader.java/1.1.2.12/Mon Feb 20 18:13:44 2006//TIMPORTACAO_COTACAO Then I added a space, removed it and saved the file. CVS/Entries remained unchanged. Only when I diffed the file after that changes were displayed. It was not possible to commit the file, even by using the old NB 4.1 CVS support. Created attachment 28957 [details]
CVS log input file
Created attachment 28958 [details]
CVS log output file
Files attached. I see: - update - update - checkout Nothing suspicious. In other words I miss commit output. Yes, it does not contain a commit, since what I did was: 1. Ran update since the file was not marked as modified, although it was different from CVS. Nothing happened, though. 2. Added a space, removed it and saved the file then ran update again. Then NB was able to detect the file has been modified. 3. I diffed the file and then it was able to show changes. Btw, what is the version of cvs server? Finally I have discovered one case in which this can happen. There should be ensured that status of files will be changed only if the response of cvs server contains information about all committed files. Automatic tests discovered following: 1. In NetBeans there are changed 3 files in package. 2. Commit is invoked on this package. 3. But if cvs server returns responce only for 2 of 3 files, then ALL of them are shown as up-to-date. This is wrong. issue #73181 relates to ppis observations. 5.5_candidate, so I plan to backport issue #73181 fix that causes this issue into release55 branch (there can be yet another unknown cause). 5.5_fix: issue #73181 backported to release55 branch What about Netbeans 5.0? That is critical! tstupka was able to reproduce even with this fix. His scenarion is somehow connected to conflicts. Similar applies to tzezula. Peter could you try to find an another reprocase? This is super critical and I certainly hope this is fixed ASAP (like today!) This has bitten today and again last week. Fortunately we caught it these times. I guess that now that we know that CVS commits can be unreliable, we can look here first if our test cases work and our QA builds don't. Could you provide details, please? Did not you get "Up-to-date check failed" in commit right before the broken commit (several reports point in this direction)? Did the pre-commit diff contain all changes (nobody remembered)? Were distributed commit mails (looks like server does not distribute any mail at all in this case)? Any other observation? Unfortunately this is an error that you may not realize has occured for a long time. It wouldn't be so bad if the "Show Changes..." reported back that the file was not up-to-date. Even if a commit is suspected to have failed, there is no way to know since the up-to-date doesn't show. There is no information on this file in our logs (we did know about the logging switch at the time). However, we did get some access errors from last week where the message was that the system could not access the file because they were in use by another process. The funny thing about this particular error is that those files don't exist in the main-line anymore. Other branches with this file have been checked out, but no projects using these files have been opened for weeks. Only the main-line project is open. It found a few folders that don't exist and in each of those few folders, it found a few files...not all the files and not all the folders. These files are not on the disk or in the CVS/Entries file either. *** Issue 75256 has been marked as a duplicate of this issue. *** According to no new reproducible steps -> INCOMPLETE. Another observations. Steps: 1. Check out project from repository. (PC 1) 2. Check out the same project from repository. (PC 2) 3. Execute "CVS | Show Changes" action. (PC 1 and PC 2) 4. (PC 1) Modify 3 files. 5. (PC 2) Modify and save one of those 3 files modified in step 4. (The same line to make a conflict). Commit this file. 6. (PC 1). Try to commit. Error dialog shows up. Invoke "Update" action from "Versioning" view. Accept the remote one). (PC 1) 8. (PC 1) From "Versioning" view invoke "Commit". All files are listed in "Commit" dialog. Push "Commit" button. All files are committed with the exception of file that was in conflict. But after the fix for this issue, file is still [Locally Modified](listed in "Versioning" view and also with blue color and Annotation in explorers). Invoking "Refresh" or "Update" action should cause that file will be up-to-date. (Cos the work file content is identical with repository content). If user modifies the file and commits it, no data are lost. (everything is in repository). Maybe "Refresh" action should be performed immediatelly after conflicts are resolved and changes are accepted. *** Issue 75254 has been marked as a duplicate of this issue. *** From what I've read, this describes a problem we've been having in my small development company while using Netbeans 5.0 to replace winCVS as well. I don't have concrete CVSLogs to prove the point, but anecdotally, this is what happens: 1. Edit locally several files. Compile, versioning calls them 'locally modified'. 2. Update from CVS. If one of the local modifications causes conflicts vs one of the repository versions, use conflict manager to resolve. 3. All files that were locally changed revert to 'up-to-date' rather than 'locally modified'. Diff results are useless. 4. Only way to resolve this is to open each file locally modified, make a trivial change (add and delete a space), and then compile. Old changes are now noted and status reverts to 'locally modified'. This must be done for every single file, and has caught us several times. This is consistant across multiple (3-6) users and dates. To " jww2nc": Problem you have described shouldn't occur in 5.5. I have seen a bug which sounds similar to this, but might not be the same. No idea how to reproduce. Was working on a project, did something which involved changing a bunch of files, committed. Days later found out that one of the files I changed had not been committed. NB CVS did not show it as modified, nor did command-line CVS, i.e. I guess timestamp was not changed? The only way to get CVS to commit it was to touch it. I can see this problem approximately once a month during last half year. Commit command always forgets some file to commit and cvs update doesn't help even if we run it several times. NB never reports any exception AFAIK. It's not possible to recognize this problem inside Netbeans, only by manual comparing cvs log of each file with its local version number. Please try to fix this. When it happens, it always takes much time to discovery it. Thanks. Petr. Can someone remember whether the file that was not committed: 1) may have been merged by a preceding update command? 2) was listed in versioning view as Locally Modified before commit? 3) was annotated in blue (in the explorer) before commit? 4) was listed in commit window prior to commit? 5) was listed in the commit log (output window) as having been committed? Please provide as much detail as possible (especially your NB version), we are trying hard to pinpoint the problem but still we are just searching for a way to reproduce it. 1) Not always 2) Yes 3) Yes 4) Yes 5) No idea misterm: your NB version? As was previously mentioned, the commit was partially fixed in 5.5 (and trunk). 5.0 jglick, phamernik: have you also experienced this in 5.0? yes, I use 5.0. So I can remember one particular case that is in CVS history. I have a feeling there were others but I can't find them; I think this was the most recent occasion. I always use daily dev builds so the javacvs code would have matched time of occurrence. On June 28 2006 I made a change to a project which involved adding several files and modifying project.properties at once. I committed as usual - perhaps using Versioning window to see all project changes, but I am not sure; I might have e.g. right-clicked the project and done Diff and Commit instead. Anyway, the result was that all the added files were committed correctly, but the modified file was not only not committed but did not show up as modified (including to command-line cvs up, cvs diff, cvs stat). It was not until July 13 that I noticed that the repository version of the file was incorrect and forced this file to be committed from my working dir (by touching it and committing from the command line). So to your questions: (1) no; (2-5) don't remember, unfortunately. I had the problem with commit in the 5.0. As far as I remember it happened in the following way: 1) I updated files before commit 2) Someone changed files in the repository 3) I did commit but it failed due to conflict 4) I've updated again and fixed conflict 5) I committed files but the file which had conflict in step 3 wasn't committed. *** Issue 80041 has been marked as a duplicate of this issue. *** OK, just happened to me again. 060808 dev build. I was modifying some files in projects/projectui. I diffed (main menu item, with project root node selected), verified that the diff was OK, and tried to commit. Failed, saying one file was out of date. Updated (main menu item) and committed again (main menu item). All files except one (*not* the one that was merged) were committed. ---%<--- IDE:------------------------------------------------- IDE: [8/11/06 2:56 PM] Diffing "Project UI" started IDE: [8/11/06 2:56 PM] Diffing "Project UI" finished IDE:------------------------------------------------- IDE: [8/11/06 2:57 PM] Committing "Project UI" started cvs server: Up-to-date check failed for `TemplateChooserPanelGUI.java' cvs [server aborted]: correct above errors first! IDE: [8/11/06 2:57 PM] Committing "Project UI" finished IDE:------------------------------------------------- IDE: [8/11/06 2:57 PM] Updating "Project UI" started M src/org/netbeans/modules/project/ui/BrowseFolders.java M src/org/netbeans/modules/project/ui/OpenProjectListSettings.java M src/org/netbeans/modules/project/ui/ProjectsRootNode.java RCS file: /shared/data/ccvs/repository/projects/projectui/src/org/netbeans/modules/project/ui/TemplateChooserPanelGUI.java,v retrieving revision 1.37 retrieving revision 1.38 Merging differences between 1.37 and 1.38 into TemplateChooserPanelGUI.java M src/org/netbeans/modules/project/ui/TemplateChooserPanelGUI.java M src/org/netbeans/modules/project/ui/TemplatesPanel.java IDE: [8/11/06 2:57 PM] Updating "Project UI" finished IDE:------------------------------------------------- IDE: [8/11/06 2:58 PM] Committing "Project UI" started Checking in BrowseFolders.java; /shared/data/ccvs/repository/projects/projectui/src/org/netbeans/modules/project/ui/BrowseFolders.java,v <-- BrowseFolders.java new revision: 1.12; previous revision: 1.11 done Checking in TemplatesPanel.java; /shared/data/ccvs/repository/projects/projectui/src/org/netbeans/modules/project/ui/TemplatesPanel.java,v <-- TemplatesPanel.java new revision: 1.22; previous revision: 1.21 done Checking in OpenProjectListSettings.java; /shared/data/ccvs/repository/projects/projectui/src/org/netbeans/modules/project/ui/OpenProjectListSettings.java,v <-- OpenProjectListSettings.java new revision: 1.22; previous revision: 1.21 done Checking in TemplateChooserPanelGUI.java; /shared/data/ccvs/repository/projects/projectui/src/org/netbeans/modules/project/ui/TemplateChooserPanelGUI.java,v <-- TemplateChooserPanelGUI.java new revision: 1.39; previous revision: 1.38 done IDE: [8/11/06 2:58 PM] Committing "Project UI" finished ---%<--- Note that ProjectsRootNode.java is listed as modified, yet it is not committed. On disk, ProjectsRootNode.java now has the correct timestamp (acc. to when it was really edited), but CVS/Entries has /ProjectsRootNode.java/1.39/Fri Aug 11 18:08:27 2006// which is the same timestamp, not the actual mod time of rev 1.39. Therefore ---%<--- nb_all$ cvs -q di projects/projectui nb_all$ touch projects/projectui/src/org/netbeans/modules/project/ui/ProjectsRootNode.java nb_all$ cvs -q di projects/projectui Index: projects/projectui/src/org/netbeans/modules/project/ui/ProjectsRootNode.java [....] ---%<--- I did not use the Versioning view at all today. I am not sure I remember, but I think PRN.java was listed in the commit dialog on the first failed attempt to commit but not on the second attempt. Reproducible, thanks a lot. A file that is merged during Update resets status of the previous reported file to up-to-date. I recommend backporting into 5.5 and 5.0 after a bit of testing. /shared/data/ccvs/repository/javacvs/libsrc/org/netbeans/lib/cvsclient/command/update/UpdateBuilder.java,v <-- UpdateBuilder.java new revision: 1.39; previous revision: 1.38 Merged into release55. /shared/data/ccvs/repository/javacvs/libsrc/org/netbeans/lib/cvsclient/command/update/UpdateBuilder.java,v <-- UpdateBuilder.java new revision: 1.30.94.1.2.2; previous revision: 1.30.94.1.2.1 *** Issue 83407 has been marked as a duplicate of this issue. *** *** Issue 70479 has been marked as a duplicate of this issue. *** The fix has been backported into release50_fixes branch. Checking in UpdateBuilder.java; /cvs/javacvs/libsrc/org/netbeans/lib/cvsclient/command/update/UpdateBuilder.java,v <-- UpdateBuilder.java new revision: 1.36.4.1; previous revision: 1.36 done |