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 :-(
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