Community
Participate
Working Groups
Steps to reproduce: 1. Create a new project in workspace default location. 2. Delete this project without deleting its contents from disk. 3. Go to File > Import > Existing Projects into Workspace. 4. Click "Browse..." to select root directory. 5. Select directory of currently running workspace. => The list with available projects is updated with the project created earlier - OK. 6. Enable "Hide projects that already exists in the workspace". => The list with projects is emptied, but there is no project in the current workspace, so nothing should be hidden - bug. The "Hide projects that already exists in the workspace" option is a new option added during 4.4.
Ah, nice find: WizardProjectsImportPage#getProjectRecords() only updated a ProjectRecord's hasConflicts field when a conflict was found. Since the "copy files" option changes what a conflict means, the hasConflicts has to always be updated. Fix committed as: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=3a3b6e0e3dc59714f0f2f4b7ecd74b21f83cd132
I can still reproduce the bug in I20140528-2000. It is worth to mention that the problem occurs only when the "Copy projects into workspace" option is enabled.
Wojciech, I understand your point, but the "Copy projects into workspace" logic causes a new project to be created under the workspace. Since a project by that name already exists from Step 1, this is a conflict. You could say that copy-import of a project from the workspace should just skip the copy and import the project directly. That should be a separate bug.
Verified in 4.4.0.I20140528-2000
(In reply to Brian de Alwis from comment #3) > Wojciech, I understand your point, but the "Copy projects into workspace" > logic causes a new project to be created under the workspace. Since a > project by that name already exists from Step 1, this is a conflict. Wojciech is right, the scenario from comment 0 is not fixed: (In reply to Szymon Ptaszkiewicz from comment #0) > Steps to reproduce: > ... > 6. Enable "Hide projects that already exists in the workspace". > => The list with projects is emptied, but there is no project in the current > workspace, so nothing should be hidden - bug. The bug is that wizard confuses workspace folder with workspace - the project from step 1 is in workspace folder but it is not in workspace, so wizard should allow to import it. (In reply to Brian de Alwis from comment #3) > You could say that copy-import of a project from the workspace should just > skip the copy and import the project directly. That should be a separate > bug. We can use a new bug to avoid messing up in RC4 but in that case the summary of this bug should reflect the bug that was actually fixed.
I understand the confusion now. I interpreted Szymon's original report as that toggling the hide option resulted in different results, which was a problem and what my patch fixed. The problem is that the language used in the UI doesn't have 100% alignment to the implementation. I originally had the hide option labelled as "hide conflicting projects" so as to match the implementation: the projects in the workspace could not be copied in since they were already in the workspace. Dani renamed the option to the current form as the original was hard to understand for the user (i.e., what situations are considered a conflict?). There's one danger in automatically handing workspace-projects as imports in that people who use the copy-projects option (like me) expect that the projects are copies and can be destructively changed. We could tweak the text to be "Hide projects that already exist in the workspace or workspace folder". That matches the implementation.
