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: | Mercurial clone blocks IDE | ||
|---|---|---|---|
| Product: | editor | Reporter: | Peter Nabbefeld <epdv> |
| Component: | Parsing & Indexing | Assignee: | Tomas Zezula <tzezula> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | P3 | ||
| Version: | 6.x | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Issue Type: | DEFECT | Exception Reporter: | |
| Bug Depends on: | 182653 | ||
| Bug Blocks: | |||
|
Description
Peter Nabbefeld
2010-02-03 03:31:08 UTC
Reassigning. vita: mercurial clone runs in IndexingBridge. We pass the target folder (where to clone the repository) to IndexingBridge.runWithoutIndexing(), but it seems that refactoring thinks scanning is running and is blocked until the scanning finishes even though the refactored file lies in a different file-tree than mercurial is cloning to. Refactoring or indexing issue? There's also another problem: Seems, that scanning is active while/after cloning, though "Scan for projects after clone" is unchecked. (In reply to comment #2) > vita: mercurial clone runs in IndexingBridge. Why? AFAIK hg clone creates a new repository and as such is not an operation that could modify any files potentially opened in the IDE. The operation creates files that the IDE does not know about yet and so it does not have to IB.runWithoutIndexing(). Or am I missing something? Guess it's running in IndexingBridge because of the possibility to look for valid NB projects after the clone. IMHO, the scanning for projects should be run as a separate process, as it seems also to slow down cloning itself (as unpacking of the clone already creates folders containing projects). Probably even the parallel scanning which seems to run though unchecked is caused by running in IndexingBridge? >refactoring thinks scanning is running and is blocked until the scanning finishes even though the >refactored file lies in a different file-tree than mercurial is cloning to.
The folder is not important, when there is a scan in progress refactoring cannot be done.
The strange think is that the "clone" causes the events starting the indexing as it creates a new folder independent on already opened roots. Unlike update.
Wrong milestone, updating. The fact that 'hg clone' runs in the protected mode (via IndexingBridge) is a little bit questionable. The reason why we have done it this way is that it can modify contents of folders that have already been scanned (eg. when cloning a repo under a folder that has already been scanned). So, strictly speaking it's sort of similar to hg fetch or cvs checkout, etc. On the other hand this is probably a corner case. Usually, people clone a repository somewhere else and then go and open projects from the new clone. In which case there is nothing in the IDE that could possibly refer to (depend on) the files being cloned. We can either remove 'hg clone' operation from the protected mode or wait for issue #182653 to be fixed. The former seems more practical the latter more correct :-). Similar problem to issue #181641. Fixed jet-main 279ac679e44d |