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.
I'm getting mid air collisions quite frequently when committing multiple times in a row on the same bugzilla's issue. Usually, the first two commits correctly append the log message in the issue. The following commits will then issue mid air collisions even if nothing was written to the bug since then. When the issue starts happening on a bug, all future commits will trigger mid air collisions until I restart Netbeans. I can supply any other details needed.
unfortunately - i wasn't able to reproduce with a current build. - what nb build do you use? - what is your bugzilla version? any chance that it is public? - could you please describe what exactly you do when this problem appears - what are your settings in the commit dialog? (fix issue, add details...). Is the issue already resolved/closed. Anything else. - it also would be great if you could run netbeans with the switches: -J-Dorg.netbeans.modules.bugtracking.vcshooks.SvnHook.level=-1 (HgHook respectivelly) -J-Dorg.netbeans.modules.bugzilla.Bugzilla.level=-1 reproduce the problem and attach your messages.log file to the issue thanks
(In reply to comment #1) > unfortunately - i wasn't able to reproduce with a current build. > > - what nb build do you use? > - what is your bugzilla version? any chance that it is public? Netbeans 6.8 up to date (Build 200912041610) Bugzilla version 3.0.3 > > - could you please describe what exactly you do when this problem appears - > what are your settings in the commit dialog? (fix issue, add details...). Is > the issue already resolved/closed. Anything else. It's not a problem that I can constantly reproduce, but it's happening rather frequently and it's quite annoying. These are the steps that I usually follow: 1. Change files in a project 2. Right click on the project, get an svn diff 3. From the diff, hit the 'Commit All' button 4. Within the commit dialog, put a log message, and hit 'Update issue' 5. Select the tracker (usually automatically selected) 6. Enter the issue number 7. Hit 'Search online..' 8. Select the issue 9. Hit Commit Once I did a first commit on the bug, Step #6 will then show the issue without having to do step #7. So at this point, I know that Netbeans cached the actual issue. The bug I've reported can only happen once the issue has been cached. However, once cached, even if I complete step #7 by hitting the issue or doing 'Search online...' again, I can reproduce it. What seems to happen is that Netbeans cached the issue I first committed on. Then for some reasons, it triggers the mid air collision, which I suspect is because the internal cache is not matching what the server has anymore. If I enter comments directly in the bug using the web portal of bugzilla between two commits, the problem seems easier to reproduce. But it is also reproducible by only committing revisions using Netbeans. > - it also would be great if you could run netbeans with the switches: > > -J-Dorg.netbeans.modules.bugtracking.vcshooks.SvnHook.level=-1 (HgHook > respectivelly) > -J-Dorg.netbeans.modules.bugzilla.Bugzilla.level=-1 > > reproduce the problem and attach your messages.log file to the issue ack. I'll start running Netbeans using these switches and as soon as I can reproduce it, I'll append more information to this issue.
> What seems to happen is that Netbeans cached the issue I first committed on. Then for some reasons, it triggers the mid air > collision, which I suspect is because the internal cache is not matching what the server has anymore. strange. nb caches the issue, thats true, but there should be a refresh just before the commit msg and an eventual resolve are submited. Lets wait for the messages.log ...
and the switch -J-Dorg.netbeans.modules.bugtracking.ui.issue.cache.IssueCache.level=-1 could be also of use
(In reply to comment #4) > and the switch > -J-Dorg.netbeans.modules.bugtracking.ui.issue.cache.IssueCache.level=-1 > could be also of use ack, applied.
I just reproduced it. These are the steps I did: 1. Changed many files.. 2. Selected all the projects in Netbeans 3. Right click -> Subversion -> Show diff 4. Hit 'Commit All' 5. Enter the issue id, hit search, hit the bug 6. Check the checkboxes to both append the message and close the bug 7. Hit commit => Everything happened correctly. It had to create two revisions to remove somes files, so +rXXX and +rXXY 8. svn up all my project from Netbeans 9. Did some minor changes to fix test cases 10. Selected all the projects 11. Right click -> Subversion -> Show diff 12. Hit 'Commit All' 13. Enter the bug id and select the issue from the drop down 14. Check the checkbox to append the log message 15. Hit Commit => Mid air collision, nothing has been written to bugzilla From the log file: FINER [org.netbeans.modules.bugtracking.vcshooks.SvnHook]: svn commit hook issue info 'Issue #2379 - Handle all other types' INFO [org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater]: Complete indexing of 0 binary roots took: 0 ms INFO [org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater]: Complete indexing of 0 source roots took: 0 ms (New or modified files: 0, Deleted files: 0) FINE [org.netbeans.modules.bugtracking.vcshooks.SvnHook]: svn afterCommit start for [...] svn commit hook message '[...]' FINE [org.netbeans.modules.bugzilla.Bugzilla]: BugzillaAutoupdate.checkAndNotify start FINE [org.netbeans.modules.bugzilla.Bugzilla]: BugzillaAutoupdate.checkAndNotify finish FINE [org.netbeans.modules.bugtracking.ui.issue.cache.IssueCache]: setting task data for issue 2379 FINE [org.netbeans.modules.bugtracking.ui.issue.cache.IssueCache]: issue 2379 was seen FINE [org.netbeans.modules.bugtracking.ui.issue.cache.IssueCache]: issue 2379 isnt changed FINE [org.netbeans.modules.bugzilla.Bugzilla]: BugzillaAutoupdate.checkAndNotify start FINE [org.netbeans.modules.bugzilla.Bugzilla]: BugzillaAutoupdate.checkAndNotify finish FINE [org.netbeans.modules.bugtracking.ui.issue.cache.IssueCache]: returning seen true for issue 2379 FINE [org.netbeans.modules.bugzilla.Bugzilla]: BugzillaAutoupdate.checkAndNotify start FINE [org.netbeans.modules.bugzilla.Bugzilla]: BugzillaAutoupdate.checkAndNotify finish FINE [org.netbeans.modules.bugzilla.Bugzilla] org.eclipse.core.runtime.CoreException at org.eclipse.mylyn.internal.bugzilla.core.BugzillaClient.parseHtmlError(BugzillaClient.java:1525) at org.eclipse.mylyn.internal.bugzilla.core.BugzillaClient.postTaskData(BugzillaClient.java:1016) at org.eclipse.mylyn.internal.bugzilla.core.BugzillaTaskDataHandler.postTaskData(BugzillaTaskDataHandler.java:367) at org.netbeans.modules.bugzilla.issue.BugzillaIssue$4.execute(BugzillaIssue.java:864) at org.netbeans.modules.bugzilla.commands.BugzillaExecutor.execute(BugzillaExecutor.java:99) at org.netbeans.modules.bugzilla.commands.BugzillaExecutor.execute(BugzillaExecutor.java:88) at org.netbeans.modules.bugzilla.commands.BugzillaExecutor.execute(BugzillaExecutor.java:84) at org.netbeans.modules.bugzilla.issue.BugzillaIssue.submitAndRefresh(BugzillaIssue.java:868) at org.netbeans.modules.bugzilla.issue.BugzillaIssue$3.execute(BugzillaIssue.java:824) at org.netbeans.modules.bugzilla.commands.BugzillaExecutor.execute(BugzillaExecutor.java:99) at org.netbeans.modules.bugzilla.commands.BugzillaExecutor.execute(BugzillaExecutor.java:88) at org.netbeans.modules.bugzilla.commands.BugzillaExecutor.execute(BugzillaExecutor.java:84) at org.netbeans.modules.bugzilla.issue.BugzillaIssue.addComment(BugzillaIssue.java:827) at org.netbeans.modules.bugtracking.vcs.SvnHookImpl.afterCommit(SvnHookImpl.java:190) at org.netbeans.modules.subversion.ui.commit.CommitAction.afterCommit(CommitAction.java:664) at org.netbeans.modules.subversion.ui.commit.CommitAction.performCommit(CommitAction.java:624) at org.netbeans.modules.subversion.ui.commit.CommitAction.performCommit(CommitAction.java:463) at org.netbeans.modules.subversion.ui.commit.CommitAction.access$100(CommitAction.java:90) at org.netbeans.modules.subversion.ui.commit.CommitAction$3.perform(CommitAction.java:288) at org.netbeans.modules.subversion.client.SvnProgressSupport.performIntern(SvnProgressSupport.java:103) [catch] at org.netbeans.modules.subversion.client.SvnProgressSupport.run(SvnProgressSupport.java:96) at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:602) at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:1084)
still unable to reproduce. - we had an upgrade since 6.8, could you please confirm if the issue still persists or not? - could it be that there is some other process witch updates the issue after the svn commit? e.g. bugtraq or some other svn repository post-commit hook
(In reply to comment #7) > still unable to reproduce. > - we had an upgrade since 6.8, could you please confirm if the issue still > persists or not? I haven't been using this feature lately. > - could it be that there is some other process witch updates the issue after > the svn commit? e.g. bugtraq or some other svn repository post-commit hook No, I'm sure about this. The only thing that was updating this bug in bugzilla was Netbeans. However, your question is a bit scary here. Even if another process would had been updating this bug 5 or 10 minutes ago, why would the plugin not refresh the issue? Shouldn't you refresh/re-fetch the issue right before modifying it? The problem would never affect the first revision committed under a specific bug number. It was always happening after "committing multiple times in a row on the same bugzilla's issue", as described in comment #0.
(In reply to comment #8) > (In reply to comment #7) > > still unable to reproduce. > > - we had an upgrade since 6.8, could you please confirm if the issue still > > persists or not? > > I haven't been using this feature lately. as mentioned, there were some changes in that area. it would be nice if you could give it one more try with an actual build. some switches changed since then. so use -J-Dorg.netbeans.modules.bugtracking.ui.issue.cache.IssueCache.level=-1 -J-Dorg.netbeans.modules.btracking.vcshooks.level=-1 -J-Dorg.netbeans.modules.bugzilla.Bugzilla.level=-1 > No, I'm sure about this. The only thing that was updating this bug in bugzilla > was Netbeans. However, your question is a bit scary here. Even if another > process would had been updating this bug 5 or 10 minutes ago, why would the > plugin not refresh the issue? Shouldn't you refresh/re-fetch the issue right > before modifying it? indeed. as already mentioned in some previous post - there is a refresh just before the issue gets modified by the hook. a possible scenario, anyway, would be that a repository hook triggers a issue postprocessing and returns before that finishes...
no response from reporter for a long time -> worksforme. please note that we upgraded the bugzilla connector library, so feel free to reopen in case you should be able to reproduce on a current build