Bugzilla – Full Text Bug Listing
| Summary: | Automatically import / remove projects from eclipse workspace on branch switch | ||
|---|---|---|---|
| Product: | [Technology] EGit | Reporter: | Kay Huber <quorg.xtn> |
| Component: | Core | Assignee: | Jens Baumgart <jens.baumgart> |
| Status: | CLOSED DUPLICATE | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | eclipse, henrik.lindberg, jal, jan.von.loewenstein, markus.kell.r, mr.everwhere, pawelec_p, pwebster, reckord, robin.rosenberg, robin, stefan.lay |
| Version: | 0.11 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
|
Description
Kay Huber
If a .project file is part of the repository the project should currently already be removed from the workspace automatically when switching to branch which does not contain the project. Is your .project file checked in? That's possible (that .project file was not checked in). Can't check anymore (dropped the repo), sorry, but I created the scenario from scratch again and the HelloWorld3 is correctly removed from workspace if I switch the branch from "feature1" to master -> the "should be automatically removed" part of the initial description already works correctly. *** Bug 338238 has been marked as a duplicate of this bug. *** We ran into the same, here's some extra info (also in duplicate bug 338238): Eclipse version: Helios Service Release 1 Build id: 20100917-0705 EGit plugin version: 0.11.3 .project files are present in all branches (they are present on the filesystem at the time that Eclipse doesn't see the project). Here's some more information. Eclipse stores metadata about a project not only in $PROJECT/.project, but also in $ECLIPSE_WORKSPACE_DIR/.metadata/.plugins/org.eclipse.core.resources/.projects/$PROJECT When you checkout a branch with a subset of projects, the .projects directory will only contain the metadata directories for the subset of projects, and the whole set isn't restored when you checkout the branch that contains all projects. Is there any chance for solution of this problem? It is a big problem to me, too... I wonder how egit should know which projects it should import after branch switch. Should it scan the whole repo for .project files and automatically import all found projects? I think that's not feasible, it could have a severe performance impact and may lead to results which a user does not want. A possible solution could be that egit remembers all the projects which were imported the last time the newly checked out branch was checked out, and tries to find and import the projects again. I'm experiencing this as a problem, too. My branches contain about 150 Projects and the existence of single projects differs from branch to branch. (In reply to comment #7) > > A possible solution could be that egit remembers all the projects which were > imported the last time the newly checked out branch was checked out, and tries > to find and import the projects again. I think that's worth a try. Can any eGit developer comment on this? (In reply to comment #7) > I wonder how egit should know which projects it should import after branch > switch. Should it scan the whole repo for .project files and automatically > import all found projects? I think that's not feasible, it could have a severe > performance impact and may lead to results which a user does not want. > > A possible solution could be that egit remembers all the projects which were > imported the last time the newly checked out branch was checked out, and tries > to find and import the projects again. It remembers, by default and checkout reports what files have appeared/disappeared, so it could act on what .project files it sees among those. I think EGit should never just automatically import any projects into the workspace that have never been manually imported. I strongly support the idea of automatically re-importing projects removed by EGit when switching back to a branch that contains them. I would however suggest NOT to simply restore all projects that were in the workspace last time this branch was active, but only those that EGit has removed. To stay with Kay's example, assume I switch from feature1 branch with projects HelloWorld1..3 to master. EGit will remove HelloWorld3, leaving me with HelloWorld1..2. Now I manually remove HelloWorld2 from the workspace and then switch back to the feature1 branch. I would now expect to see HelloWorld1, HelloWorld3 (re-imported by EGit) but not HelloWorld2 (not previously removed by EGit, so not re-imported). Another idea regarding the automatic removal: I would very much prefer EGit to just close the projects in my workspace instead of removing them. This way I won't go on a wild goose chase for projects that I "know" must be somewhere in my workspace... Of course all ideas about re-importing projects would equally apply to reopening them in this case :) (In reply to comment #9) > It remembers, by default and checkout reports what files have > appeared/disappeared, so it could act on what .project files it sees > among those. That sounds like the right solution. (In reply to comment #10) > I think EGit should never just automatically import any projects into the > workspace that have never been manually imported. I don't agree on that one. IMHO projects can "appear" or "disappear" after a branch switch either because I myself was adding or removing a project in that branch some time before, or I've pulled a change where projects in that branch have been added or removed by somebody else. If I had added a project myself, I _was_ having the project "imported" in the workspace (since that's automatically the case, if I add a new project in my workspace...), thus I would expect it to re-appear if I switch back to such a branch. If I switch to a branch that I just pulled from a remote repo, I would expect to have all projects imported to my workspace in order to have "the same projects available" as the one had, that added a project and pushed it to the remote repo. Or let me phrase the whole thing differently: Why would you not want to have all new .projects appear? (In reply to comment #11) > Another idea regarding the automatic removal: I would very much prefer EGit to > just close the projects in my workspace instead of removing them. This way I > won't go on a wild goose chase for projects that I "know" must be somewhere in > my workspace... Well, if you switch to a branch, that doesn't have the according project, it will "remove" the whole directory in the file system (working directory) - this is already the case btw. Thus, only closing the project would still not make it re-openable without switching back to the branch where it resides in. (In reply to comment #12) > If I had added a project myself, I _was_ having the project "imported" in the > workspace (since that's automatically the case, if I add a new project in my > workspace...), thus I would expect it to re-appear if I switch back to such a > branch. In that case you already had the project in the workspace previously, so I would expect the same. Sorry if my phrasing was unclear there, I just don't want EGit to import new projects that I never had in my workspace previously, so I essentially stay in control of what I have in my workspace and what I don't. > If I switch to a branch that I just pulled from a remote repo, I would expect to > have all projects imported to my workspace in order to have "the same projects > available" as the one had, that added a project and pushed it to the remote > repo. > > Or let me phrase the whole thing differently: Why would you not want to have all > new .projects appear? Because I usually only have a subsection of all available projects of the repository in my workspace - just the projects that I need. And I don't want a SCM tool to pollute my workspace with additional projects I don't need just because somebody has added them to the repository. Take the Eclipse MDT repository for example: it currently contains 214 projects ranging from BPMN over OCL to UML. I only need the UML stuff, and only a subsection of that (6 projects currently). Just because someone upstream commits a half-dozen new BPMN projects to the repository doesn't mean I want them cluttering my workspace. Also, I think setting up your workspace with all required projects is not a task for a SCM tool but better left to tools like Buckminster or m2eclipse. > Well, if you switch to a branch, that doesn't have the according project, it > will "remove" the whole directory in the file system (working directory) - this > is already the case btw. Thus, only closing the project would still not make it > re-openable without switching back to the branch where it resides in. My point is that I can at least still see them and have an (admittedly poor) indicator (the closed state) for "this project doesn't exist in this branch", while just removing the project leaves me wondering where it's gone (did I misplace it in another working set? did I f*** up my workspace again? oh no, it's just not in the current branch, silly me...). I don't really mind that the project is not openable, at least I get a message to that regard, hopefully reminding me that it's not in the current branch - if the closed icon didn't already accomplish that... If we close the project, rather than delete it, I think it should be decorated so we see that it is closed because it not available, rather than because the user closed it manually. Not importing projects automatically is kind-of-dangerous, because you may will perform changes without realizing that there are more projects than you see that you should also change. Then you commit, push and break things. Eclipse should automatically import projects it has never seen. What would the reason be not to do it (other than it hasn't done it before). We could give the user an option to close/remove projects as well as whether to import/reopen. (In reply to comment #14) > If we close the project, rather than delete it, I think it should be decorated > so we see that it is closed because it not available, rather than because the > user closed it manually. That would be great. > Not importing projects automatically is kind-of-dangerous, because you may > will perform changes without realizing that there are more projects than > you see that you should also change. Then you commit, push and break things. > > Eclipse should automatically import projects it has never seen. What would the > reason be not to do it (other than it hasn't done it before). For the same reasons I outlined above. I don't want all the projects cluttering up my workspace (and having 200+ projects auto-imported and built automatically on top of what I already have in my workspace for no good reason is no fun at all). Plus, I think the one having the final word about what's in the workspace should be me, not my IDE - and I don't like cleaning up after my tools every time they try to do something clever and automagical ;P I see your point about the kind-of-dangerous part, but I prefer to be able to do things my way while being aware of the risks involved instead of my tools trying to protect me from myself... So far, the number of times this has bitten me in the rear end has been fairly limited. > We could give the user an option to close/remove projects as well as whether > to import/reopen. I think a preference might be the best idea, especially for the "import new projects" case. Clearly there are conflicting interests involved with that feature. (In reply to comment #11) > Another idea regarding the automatic removal: I would very much prefer EGit to > just close the projects in my workspace instead of removing them. This way I > won't go on a wild goose chase for projects that I "know" must be somewhere in > my workspace... > Of course all ideas about re-importing projects would equally apply to > reopening them in this case :) The projects are deleted to avoid an inconsistent state: Checkout deletes a .project file but the project remains in the workspace. So I thought deleting the corresponding project in the workspace is a clean solution. We could add an option to look for new projects in the repository on checkout and ask the user to import the new projects. This bug sounds pretty much the same as bug 350866, with similar conclusions: - User should be in control of projects in the workspace (including their placement in working sets). - EGit should not automatically add/remove projects without asking - Closing/reopening projects seems to be the best solution EGit could add a persistent property to projects that it closed because they are not available in the new branch. This property could be used in a decorator to distinguish user-closed projects from the Git-closed ones. If the property stores the branches in which the project was originally open (or closed), then EGit could automatically reopen projects after switching branches, without reopening projects that the user closed manually. (In reply to comment #17) > This bug sounds pretty much the same as bug 350866, with similar conclusions: > - User should be in control of projects in the workspace (including their > placement in working sets). > - EGit should not automatically add/remove projects without asking > - Closing/reopening projects seems to be the best solution > > EGit could add a persistent property to projects that it closed because they > are not available in the new branch. This property could be used in a decorator > to distinguish user-closed projects from the Git-closed ones. If the property > stores the branches in which the project was originally open (or closed), then > EGit could automatically reopen projects after switching branches, without > reopening projects that the user closed manually. That sounds reasonable +1 to that proposal. If a branch switch removes a checked-in .project file I think it is correct to delete the project in the workspace. Otherwise you have an inconsistent project in the workspace causing follow-up errors. (In reply to comment #19) > If a branch switch removes a checked-in .project file I think it is correct to > delete the project in the workspace. Otherwise you have an inconsistent project > in the workspace causing follow-up errors. I disagree. Besides the arguments already given above, try the following: - create a project in eclipse - close eclipse - delete or move the project folder in the file system - restart eclipse The project will still be there in your workspace, but is closed now. This is not quite optimal, because you don't get notified about the cause. But at least nothing vanishes magically and you stay in control of your workspace projects. This was fixed with bug 350866, I think. If there are still problems with the current behavior, please open a new bug report. *** This bug has been marked as a duplicate of bug 350866 *** |