On the latest build in Windows just noticed that after a clone the cloned project is not displaying the clone label in
the project view. This is a regression, nothing has changed in this area in the Mercurial side.
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
- 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...]"
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.
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. ***