I am seeing this on Solaris also. It occurs with both mercurial 0.9.5 and
mercurial 1.0.

If I create an NBM and install it in NetBeans 6.1 then a cloned project is
displayed correctly.
This suggest that something has changed in NetBeans trunk which affects how we
annotate a project.

When annotateName is called for a project directory it looks like the
VCSContext consists of all the files and
directories in the project directory instead of the project directory.

It looks like the change below to
projectui/src/org/netbeans/modules/project/ui/ProjectsRootNode.java is the
cause of 
our problem.

- String result = hstat.annotateNameHtml(super.getDisplayName(),
Collections.singleton(proj.getProjectDirectory()));
+ String result = hstat.annotateNameHtml(super.getDisplayName(), files);

This is changeset 585ba313709f from May 16th.

For projects not using an external source root it should be true that files ===
Collections.singleton(proj.getProjectDirectory()). Do you have straightforward
steps to reproduce the problem that I can
try? (I.e. how to make the project to test, what kind of repo it is in, how you
clone it, ...) I don't know what a
"clone label" would even look like; I don't remember ever seeing such a thing.

1) Invoke File | New Project. Create a Java project
2) Select project node (in my case JavaApplication16)
3) Invoke Versioning | Mercurial | Initialize Project
4) Invoke Versioning | Commit
5) Invoke Versioning | Clone JavaApplication16; press Clone button

A new project is created.

On NetBeans 6.1 the project node contains JavaApplication16
[JavaApplication16_clone0].
Now it just contains JavaApplication16.

The issue is that if d is project.getProjectDirectory(),

hstat.annotateNameHtml("x", Collections.singleton(d)) => "x [clone...]"

whereas e.g.

hstat.annotateNameHtml("x", Collections.singleton(d.getFileObject("src"))) =>
"x"

The reason that the new BadgingNode considers the direct children of the
project directory, rather than just the project
directory itself, is given in issue #78994 and described in a comment in the
source file: annotateIcon and similar would
otherwise incorrectly mark a parent project as modified when the only
modifications were really to a nested project
sharing the same repository, since annotation of a directory is considered to
mean annotation of all of its descendants
in a tree. (Ideally BN would precisely enumerate all the files in the parent
project not owned by a nested project and
ask to annotate this set; but this would be expensive in terms of disk I/O as
well as CPU, since there is no way to
quickly obtain all nested projects, so the compromise solution that works for
most cases is to assume that any nested
projects are direct children.)

This special treatment was originally applied to just the EAR project type and
a couple of others which routinely have
nested projects, even though any project type may run into this scenario since
NB does not restrict you from creating
nested projects of general type. My commit, as part of cleaning up the
treatment of project root node badging,
centralized the logic. BadgingNode was already doing automatic display name
badging but project types were doing icon
badging; the cleanup moves both kinds of badging into BN so that project types
need not have any special code for this.

The regression is due to the fact that even for EAR projects, the display name
badging was done by BN, with no fix for
#78994, whereas after the cleanup, all of the badging is done on a consistent
file set with the #78994 fix. It would
appear that at least in the case of Mercurial, the VCS implementation behaved
correctly for icon badging when passed the
direct children of the project dir, but does not behave consistently for
display name badging.

Of course instead of fixing the Mercurial module it would be possible to revert
BN to using the singleton project
directory as the file set for display name badging, while using its children
for icon badging. Besides being a
perplexing inconsistency, this would mean the fix for #78994 would not work for
a VCS which indicated modification
status in the display name instead of (or in addition to) the icon.

Sorry this is such a long explanation but I hope it makes sense now.

I understand that for a project node the VCSContext passed to annotateNameHtml
consists of all the files and directories
in the project directory rather than the project directory.

Another question:

What is in the VCSContext for any other file or directory? Is it just that file
or are there other cases where the
VCSContext can contain more than one element?

There may be other cases where the Set<FileObject> is not a singleton; for
example, the Important Files node in an NBM
project (and I think there is something similar for web app projects).

*** Issue 136782 has been marked as a duplicate of this issue. ***

fixed f8f76bdd883e