| Remove deleted projects with Oomph [message #1748106] |
Fri, 18 November 2016 14:03  |
 Silvestre Martins
Messages: 84
Registered: July 2009 |
Member |
|
|
We are working on a legacy project that contains old plugins that are being removed in the context of refactoring tasks. So frequently we delete the projects from the workspace.
We have an Oomph Project Import task reads the projects from a psf file. This works as expected. And when we delete a project, we also remove it from the file.
However, we always need to tell all developers to delete the project manually from their workspace.
In cases where the project was simply moved but name is the same, this is even worse, because now Oomph fails because it detects a new project, but cannot import it because there's already a project with same name.
So in this case developers need to delete the project manually, and restart Eclipse to rerun the import task.
It would be nice if Oomph could support the "un-import". This way we simply needed to maintain a list of deleted projects, as we do with .gitignore file (to avoid projects being added back again during merges).
Is there a way to achieve this result with existing functionality?
[Updated on: Fri, 18 November 2016 14:05] Report message to a moderator |
|
|
|
| Re: Remove deleted projects with Oomph [message #1748156 is a reply to message #1748153] |
Sat, 19 November 2016 12:45  |
Silvestre Martins
Messages: 84
Registered: July 2009 |
Member |
|
|
This is a recurrent task, not a one-time refactoring, this I would like to have a more transparent workflow to deal with deleted/moved projects.
If user deletes or moves a project in local clone, doing a Git pull won't cause any trouble, unless there are changes in files inside that project, mas that's something the developer is deleting the project must deal with, as any other Git merge conflict.
The problem is when these changes are pushed into remote. Other developers will then do a Git pull and existing project becomes obsolete (usually project is still present in the workspace but empty). This is not so relevant for deleted projects, but for moved projects it creates problems because Oomph fails to perform the Project Import task, and developers that are not aware of changes on that particular project, don't understand why it fails.
I see a workaround for the "location moved" use-case: always change the project name - this way Oomph won't fail anymore because there's a project with same name in the workspace already.
I was just wondering if there would be another way to handle this.
|
|
|
| Re: Remove deleted projects with Oomph [message #1748172 is a reply to message #1748156] |
Sun, 20 November 2016 08:24 |
Ed Merks
Messages: 33264
Registered: July 2009 |
Senior Member |
|
|
Silvestre Martins wrote on Sat, 19 November 2016 07:45This is a recurrent task, not a one-time refactoring, this I would like to have a more transparent workflow to deal with deleted/moved projects.
I wouldn't have expected deleting an moving projects to be a common recurring task...
Quote:
If user deletes or moves a project in local clone, doing a Git pull won't cause any trouble, unless there are changes in files inside that project, mas that's something the developer is deleting the project must deal with, as any other Git merge conflict.
The problem is when these changes are pushed into remote.
Yes, that was my point. The other uses must do a pull and then they have a whack of problems...
Quote:
Other developers will then do a Git pull and existing project becomes obsolete (usually project is still present in the workspace but empty).
Exactly, and that would seem like something that could be addressed. After all, if a project is in the workspace and is connected to a git clone, after the pull, if the project is no longer in the clone, it would seem reasonable to expect the project also no longer be in the workspace...
Quote:
This is not so relevant for deleted projects, but for moved projects it creates problems because Oomph fails to perform the Project Import task, and developers that are not aware of changes on that particular project, don't understand why it fails.
But also if you do things manually, you must also first delete the workspace project before you can import another project. So you seem to be focused on tasks that delete projects but it seems to me EGit might do more to handle this case...
Quote:
I see a workaround for the "location moved" use-case: always change the project name - this way Oomph won't fail anymore because there's a project with same name in the workspace already.
I was just wondering if there would be another way to handle this.
I suppose Oomph could do some additional processing before performing tasks that might import projects. E.g., it could look for closed projects for which there is no underlying file system backing it, and delete such projects from the workspace. On could argue that the project set importers (team-implementation-specific) themselves should do that.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Powered by
FUDForum. Page generated in 0.03587 seconds
] 
Search
Help
Register
Login
Home
