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.

Bug 180193 - Mercurial clone blocks IDE
Summary: Mercurial clone blocks IDE
Alias: None
Product: editor
Classification: Unclassified
Component: Parsing & Indexing (show other bugs)
Version: 6.x
Hardware: PC Windows XP
: P3 normal (vote)
Assignee: Tomas Zezula
Depends on: 182653
  Show dependency tree
Reported: 2010-02-03 03:31 UTC by Peter Nabbefeld
Modified: 2012-01-26 12:46 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description Peter Nabbefeld 2010-02-03 03:31:08 UTC
Though cloning a mercurial repository has nothing to do with open projects, refactoring, running etc. are blocked. As mercurial fetch is running for a long time (interrupted it after about 1 hour), this makes the IDE unusable :-(
Comment 1 Peter Pis 2010-02-03 03:55:05 UTC
Comment 2 Ondrej Vrabec 2010-02-03 08:23:31 UTC
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?
Comment 3 Peter Nabbefeld 2010-02-03 09:00:42 UTC
There's also another problem: Seems, that scanning is active while/after cloning, though "Scan for projects after clone" is unchecked.
Comment 4 Vitezslav Stejskal 2010-02-04 01:19:31 UTC
(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?
Comment 5 Peter Nabbefeld 2010-02-04 02:35:09 UTC
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?
Comment 6 Tomas Zezula 2010-02-10 07:45:21 UTC
>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.
Comment 7 Tomas Zezula 2010-02-10 07:45:45 UTC
Wrong milestone, updating.
Comment 8 Vitezslav Stejskal 2010-05-04 13:12:59 UTC
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 :-).
Comment 9 Tomas Zezula 2010-11-18 08:07:58 UTC
Similar problem to issue #181641.
Fixed jet-main 279ac679e44d