| Summary: | [Import/Export] Importing project with the same nazme as other project that is already in the workspace | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Jakub Jurkiewicz <jakub.jurkiewicz> |
| Component: | UI | Assignee: | Tod Creasey <Tod_Creasey> |
| Status: | RESOLVED DUPLICATE | QA Contact: | |
| Severity: | normal | ||
| Priority: | P5 | CC: | antoine, curtis.windatt.public, delmyers.cs+eclipse, freidin.alex, helmut.haigermoser, Irit.Belezko, leticiacpassos, mark.melvin, pascal, remy.suen, sandakith |
| Version: | 3.3 | Keywords: | helpwanted |
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
|
Description
Jakub Jurkiewicz
Tod, I saw that you marked this bug as helpwanted. How do we want to resolve this? I think the warning would be suffecient. if we try and get too smart about it we will likely just frustrate someone who knows what they are doing. *** Bug 157885 has been marked as a duplicate of this bug. *** As I have been investigating this already I can try to prepare a patch in the near future. I think about checking if the project being imported is already in the workspace folder. If it is, then the dialog should be displayed with the message (e.g. "Folder with the same already exists in the destination location" or something similar) and the user should have an option to overwrite or to cancel. Is it good direction? Perhaps we should show them as two lists in the import dialog or show the exisiting ones differently. Two dialogs would make it hard for the user to play around with the configuration they want. We will also need to consider deleting the old project when we import the new one. (In reply to comment #6) > Perhaps we should show them as two lists in the import dialog or show the > exisiting ones differently. I proposed a patch for Bug #163601 and the solution was to gray out the already existing projects and to allow to overwrite them. What do you think Tod about that patch? *** Bug 195544 has been marked as a duplicate of this bug. *** *** Bug 197781 has been marked as a duplicate of this bug. *** *** Bug 198160 has been marked as a duplicate of this bug. *** *** Bug 199368 has been marked as a duplicate of this bug. *** Hi, I don't agree with the priority of this bug. In my work environment, we have a lot of little projects. Our QA teams tests more than 200 projects a day, and then share them as they find defects. This bug is really limiting the Eclipse user experience. Is it possible to raise the priority of this bug ? Can we have a target milestone for it ? This is not in the plan for 3.4 but we would be happy to look at a community patch. (In reply to comment #13) > This is not in the plan for 3.4 but we would be happy to look at a community > patch. Tod, what do you think about patch noted in comment 7? Just adding my two cents: The process of importing an existing project into the workspace is very similar to checking-out from CVS. The current process followed by CVS is that, if you choose to check it out as the same name as one that exists in the file system, but has been deleted from the workspace, the existing project is just deleted. There is no option for matching existing files. Should the same sort of process be followed here (except with a possible "change project name" option)? Just to keep consistency. There is a sensible difference (if I remember right) in the fact that you can import more than one project at a time, so you have a list of projects available, while you can only import one project at a time in CVS. To have the possibility to change the name of the project would be great. At a minimum seeing the projects that cannot be imported as disabled in the list would be good already. I will try the patch on my machine soon. Thanks for contributing it. I don't understand: I can check-out more than one project at a time in my version of Eclipse. My bad then. Tod, can you please mark this bug as a duplicate for https://bugs.eclipse.org/bugs/show_bug.cgi?id=163601 ? *** This bug has been marked as a duplicate of bug 163601 *** |