Bug 194147, comment 31 shows a general problem for people using Hg or Git via command line. Parsing API can trigger too soon, before whole repository is updated.
> In parsing.api we have no special handling of
> events from external processes, we depend on FileSystem events. We do some
> things to improve the performance by handling events from single atomic action
> by one transaction with correct ordering of event types.
> We also have a special contract with VCS module to suspend listening (events
> are buffered) when VCS operation is running
What you are describing is a problem and yes, it is a VCS related bug.
parsing.api should not start reparsing when there is an VCS operation in
progress. Right now this works for operations done from inside of the IDE. It
does not work for operation performed externally (which I believe is a bug;
fixable in Hg case at least) and if VCS guys agree, we should report it as
In an email conversation VCS guys said that they can check for "wlock" file in .hg directory (something similar for Git). There can be stalled lock (possibly detectable by using java.nio.FileLock). According to Tomáš Stupka, something similar might be possible for svn 1.7.
afaik what http://netbeans.org/bugzilla/show_bug.cgi?id=194147#c31 is about is a contract between indexing and the netbeans versionig modules when they (the vcs modules) run commands and not about the netbeans versioning support taking over the responsibility for externally invoked commands - in so far, no bug.
I do not think this is worth to implement as it will not address the problems described in the issue 194147 - to resolve issue 194147 you would need to block parsing API when *multiple* VCS external operations are being executed. But NetBeans VCS support has not idea when multiple external operations were started and when they are finished. There is no way you can ever know that.
This is WONTFIX IMO if the only reason was the issue 194147.