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.

Bug 135521 - Mercurial Project - cloned project label not displaying
Summary: Mercurial Project - cloned project label not displaying
Status: RESOLVED FIXED
Alias: None
Product: versioncontrol
Classification: Unclassified
Component: Mercurial (show other bugs)
Version: 6.x
Hardware: Sun All
: P3 blocker (vote)
Assignee: issues@versioncontrol
URL:
Keywords:
: 136782 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-05-21 16:47 UTC by John Rice
Modified: 2008-06-23 16:39 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description John Rice 2008-05-21 16:47:16 UTC
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.
Comment 1 Padraig Obriain 2008-05-22 10:16:46 UTC
I am seeing this on Solaris also. It occurs with both mercurial 0.9.5 and mercurial 1.0.
Comment 2 Padraig Obriain 2008-05-22 10:47:01 UTC
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.
Comment 3 Padraig Obriain 2008-05-22 11:16:09 UTC
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.
Comment 4 Padraig Obriain 2008-05-22 11:26:58 UTC
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.
Comment 5 Jesse Glick 2008-05-23 14:50:41 UTC
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.
Comment 6 Padraig Obriain 2008-05-23 15:07:17 UTC
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.
Comment 7 Jesse Glick 2008-05-23 17:54:07 UTC
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.
Comment 8 Padraig Obriain 2008-05-24 10:20:05 UTC
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?
Comment 9 Jesse Glick 2008-05-27 18:48:23 UTC
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).
Comment 10 Tomas Stupka 2008-06-13 19:38:50 UTC
*** Issue 136782 has been marked as a duplicate of this issue. ***
Comment 11 Tomas Stupka 2008-06-23 16:39:31 UTC
fixed f8f76bdd883e