Community
Participate
Working Groups
master A project's location should be stored relative to the workspace root if the project is stored inside a subfolder of the workspace (can be a physically nested project as in bug 44967 or just a project inside a folder inside the workspace). Currently, project locations are either a) directly inside the workspace, or b) at an absolute file system location c) relative to a user-defined workspace path variable When I (or Egit, see bug 358285) create a project whose location is inside the workspace, I expect this project to still work after I've moved the workspace root to another location on the file system. This is currently not the case, unless I manually used approach (c) and manually updated the path variable when moving the workspace. Eclipse workspaces have always been designed to be moveable/copyable on the file system, but with EGit, this doesn't work any more. EGit requires a separate root folder (working directory) for each repository, and the best way to keep the repositories manageable is to store the root folders inside the workspace. When a new project is created, core.resources should check whether its location is inside the workspace. If it is, then the location should be stored relative to the workspace, e.g. using a predefined path variable like the WORKSPACE_LOC that is already available for linked files and folders (but not for projects).
Exporting and importing a Team Project Set also doesn't work well as a workaround for EGit use cases, see bug 395143.
Moving/renaming a workspace is a basic workflow that has effectively been broken with the move to Git. Please put this bug on the 4.5 plan. Potential workaround: Here's an ugly command line hack to repair project associations in workspace "4.4_maintenance", which came to life as a copy of "4.3_maintenance": find <path-to-workspace>/.metadata/.plugins/org.eclipse.core.resources/.projects -name .location -exec sed -i 's/4\.3_maintenance/4\.4_maintenance/g' {} \; And to fix EGit repositories: find <path-to-workspace>/.metadata/.plugins/org.eclipse.core.runtime/.settings/ -name "*.prefs" -exec sed -i 's/4\.3_maintenance/4\.4_maintenance/g' {} \;
Bug 358285 has been fixed in EGit 4.3, so this is the only remaining problem for workspace portability when using git repos inside the workspace (which is the best setup if you have to work on multiple branches in parallel). (In reply to Markus Keller from comment #2) The second command should be unnecessary since EGit 4.3. WARNING: The first command only works if the search and replace patterns in s/search/replace/g have the same length in UTF-8! I.e. it works for 4.3 -> 4.4 etc., but it won't work for 4.9 -> 4.10 or if you want to move the workspace to a different location. The problem is that <path-to-workspace>/.metadata/.plugins/org.eclipse.core.resources/.projects/*/.location uses a !@#$% binary format for no good reason, and longer/shorter strings would need adjustments to the "UTF length", see code in LocalMetaArea#readPrivateDescription(..). To see the matches before changing them in-place, replace ... -exec sed -i 's/4\.3_maintenance/4\.4_maintenance/g' {} \; with ... -exec grep -aH --color '4\.3_maintenance' {} \;
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
Since bug 559692 is mostly the same there is no reason to believe this is fixed. While bug 559692 suggested a separate operation to move/copy a workspace and as part adjust the location path, I would prefer the relative paths a described in this bug.
