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.
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 1.0.0.42.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 Mercurial->Add menu. 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 RANDOM keyword. 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 previous comment: 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 resolved.
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.
Verified