I am trying to include the workspace for projects in a revision controlled environment (git) so that when a project is checked out the SVE workspace is functional wherever one might clone to.
The structure that I have is a src directory that is outside of the workspace. When files are imported I use links.
It seems however that whenever I try an clone the project to a different location workspace no longer works.
1) Is there anything special that I need to do to be sure that all file paths are relative?
2) What files need to be checked into the RCS so that the project can be opened in the new directory.
Checking in a workspace isn't a good idea, because platform-specific files and absolute paths are present in the workspace files.
With respect to setup, the generally-recommended Eclipse workflow is:
- Create an Eclipse project stored on the filesystem (not in the workspace)
- Setup any project-relative linked folders either relative to the project directory or relative to a variable
When setting up a new workspace:
- (optional) set any global variables
- Import project(s) into the workspace
With this workflow, the workspace is a temporary container.
One Eclipse feature I haven't personally used, but could be helpful, is Eclipse project set files. See: http://help.eclipse.org/juno/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Fguide%2Fteam_resources_projects.htm
Hope this helps!
The flow we use is to store the .project and .svproject (which contains environment variables for all paths, set elsewhere) in our repo along with the chip. When the user checks out an area, the next step is to File>Import>General>Existing Projects into Workspace. Browse to the .project (usually at the top of the chip) and off we go.
There is a bit of an internal debate on how to manage multiple chips / user areas. Having the workspace completely de-coupled from the chip, means that a given work space can import mutiple chips. When comparing two different files Ctrl+Shift+R>top will bring up both "top" files and makes it easy to compare etc.
On the other hand, having a workspace per user area / chip keeps things "neat" and switching between chips is fairly seamless.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.