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.
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 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