It happened to me that when I added new interface, its status was marked as
locally new (yellow). I wasn't able to commit it until I made some changes and
saved it. I am unable to reproduce it now, but obviously it can happen.
NB build 070501, Mercurial module version 18.104.22.168.1
Can you describe exactly what you did? Where you in a new project or an already
existing one. How did you add the new interface - what view where you in? Did
you right click on the project node and so on.
The more detail we get the more likely we will be able to reproduce it.
Well I created a new project, and invoked Initialize Repository from main menu.
Then I commited the project - it had only main.java file as a source. Then I
invoked New | Java Interface... from the context menu invoked in Projects view
on the same package as was main.java. But the interface was yellow as I
described before. I didn't notice I can invoke Mercurial | Add, so I made some
changes to that file and saved it. After it it was green as expected.
Is there a use case where the file is expected to be yellow? Because I
encountered yellow statuses several more times...
We implemented the fileCreatedImpl() in MercurialVCSInterceptor.java (extends
VCSInterceptor) so newly created files the IDE knows about would be
automatically added to Hg repository for the user. Before we had done this all
locally new files (marked as yellow) had to be added to the repository using the
This was meant to work for all cases, except when a new file is created outside
of NetBeans when the IDE is turned off. If we can get reproducible test cases
where the file added is staying in the locally new state then this is a bug that
we should fix. I tried your scenario and it worked fine for me. I do see the
file turn yellow for a brief instance and then it goes to green as it's status
is changed to locally added.
If it's intermittent we should release note it, telling users that if they add a
locally new file (indicated in yellow) they can directly add it to the
repository using (Mercurial-> Add).
Just tried to get a locally new file to appear in a Hg project by following the
steps above of creating it in the project with the IDE shut down. What happens
now is that it is no longer marked as locally new and so I can't get at the
Mercurial-> Add menu to add it.
I tried the same scenario myself, but was unable to reproduce, so I used the
Well I encountered yellow status several more times when I tested the module
today. What was the weirdest, I had one blue (modified) and three green (new)
files. After an action, the blue became green and those green became yellow.
Unfortunately I am not sure what the action was. I think it was rollback, but I
am not really sure :( I tried to reproduce it, but without any success... That's
why I asked if the yellow status can be achieved from the IDE in any way. I
would expect it shouldn't be possible (only for that short period of time after
creating new file). But it seems that under some circumstances it can happen.
Ahh - was wondering about the RANDOM keyword :) This is certainly puzzling. We
had some other issues with locally new and locally added. One suggestion was to
just mark all locally new files as locally added in the IDE, but not in the Hg
Repository. Their real Hg status would only change when a commit was done using
the hg addremove, which would add and commit at the same time.
One to look into further but will be a 1.1 issue to solve I think.
I've just figured out how to reproduce those yellow statuses I described in
1) Add a new file (the file is green)
2) Invoke rollback (the file is still green)
3) Invoke commit (that file changes to yellow after it)
However, I still didn't manage to reproduce the original problem - yellow status
immediately after adding new file.
Great - this test is explained by the rollback action not initiating a change
event on the files effected by the rollback. This is also causing inline diff
problems (see 103103). By adding a refresh after the rollback if any files have
been effected we should sort out this issue below and the the inline diff issue.
Now as you say there may be other issues lurking, but this at least should be
I am closing this as INVALID.
We have changed the implementation of the mercurial module so that files remain Locally new until they are committed.