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: | Changing task is running when userdir is in mercurial repository | ||
|---|---|---|---|
| Product: | versioncontrol | Reporter: | Jiri Skrivanek <jskrivanek> |
| Component: | Mercurial | Assignee: | issues@versioncontrol <issues> |
| Status: | VERIFIED FIXED | ||
| Severity: | blocker | CC: | msandor |
| Priority: | P1 | ||
| Version: | 6.x | ||
| Hardware: | All | ||
| OS: | All | ||
| Issue Type: | DEFECT | Exception Reporter: | |
| Attachments: |
messages.log with mercurial logging.
proposed patch additional patch |
||
|
Description
Jiri Skrivanek
2008-02-04 07:52:43 UTC
Created attachment 55973 [details]
messages.log with mercurial logging.
Added Maros to CC list so we can discuss whether we should or can restrict change notifications. The file for which we get Change notification being complained of is build.properties. Should we special case ignoring changes to that file? It is OK for mercurial to react to file change events and I think it should not be hacked in any way. I see a lot of changes to build.properties file in the log, maybe the problem is in the module that touches the file so frequently. Or it might the problem that every change of this file adds a new "Changing..." task to the queue. And it waits until previously started task for the same file finishes. IMO, if there is a new change event for the same file, it should cancel previous "Changing..." task. Yes, this can also be the case. Maybe all change events could be coalesced, not just events for one file. Ok - if we are getting lots of changing events then who is responsible for coalescing them? I assume its the component that's generating them, or do you mean we should be coalescing them at our end? Yes, mercurial could be doing that. Subversion does that too in its cache. It collects file changes that happen while a refresh is in progress and then when refresh finishes it looks if there are any new events and processes them. This way refresh tasks do not stack in the queue. I have noticed an error in fileChangedImpl which causes refresh to be done twice. I will fix that first. Created attachment 56139 [details]
proposed patch
changeset: 66044:b9d6fd22c4b0 tag: tip user: padraigob@netbeans.org date: Wed Feb 06 08:49:26 2008 +0000 files: mercurial/src/org/netbeans/modules/mercurial/MercurialInterceptor.java description: Correct change to fileChangedImpl to not refresh ignored files. I have pushed this change. Created attachment 56147 [details]
additional patch
changeset: 66051:84ed214820b7 tag: tip user: padraigob@netbeans.org date: Wed Feb 06 10:05:15 2008 +0000 files: mercurial/src/org/netbeans/modules/mercurial/FileStatusCache.java mercurial/src/org/netbeans/modules/mercurial/MercurialInterceptor.java description: 126588: Reduce number of FileStatusCache.refresh calls for FileCreation and FileChanged events I have committed the additional patch. This should reduce the 1 the total number of "hg status" calls made because of changes to build.properties for the attached messages.log. Verified. Thanks. |