i have added a workspace(c:/users/aparna/workspace)and checked out the codes there. Due a mapping issue i changed the workspace, that is i created a new one (d:/noscript). When i tried to check out the project modules to this new workspcae from tfs, it is already mapped to the old workspace. When i open new workspace folde, .metadata and remotesystemTempFiles are seen. Projects modules still resides in old workspace. When i open eclipse by selecting new workspace, i got all project modules resides in old workspace.. what is the reason for this? Will it make any performance issue?
In TFS, one workspace does not allow the same TFS folder to be mapped to more than one local directory.
However, you can have two or more workspaces for one computer, and each workspace can map a TFS folder to a different local folder. Seems your project modules already mapped with the old workspace.
This will not cause any performance issue. But what revisions of files are in each workspace is tracked separately (to keep each up to date you need to do a get in each) One easy way is using tf get from the command line.
If you don't want to track files separately in two workspaces, you could remove the mapping with old workspace for all the project modules. Select the old worksapce, go to Team Explorer-> Source Control - Right click on folder/project you've got before - Select Remove Mapping
Then you could remap and get latest in the new workspace.
Related
I am confused with a mapping issue in TFS. I checked out the projects from TFS into my workspace without creating the TFS folder hierarchy. That is, I directly check out all the projects into my workspace. After that, my boss suggested me to check out the projects as TFS folder hierarchy. I checked out a project based on TFS hierarchy. That is, I root folders are created and that project checked out inside that. Now I have to move other projects that are directly checked out in the workspace into that root folder.
how can I do this? So I created a new workspace and tried to check out the code again. But currently, my local path is pointing to previous workspace folder.. how can I change this and fresh check out of those projects...?
According to your java, eclipse tag, seems you are using Team Explorer Everywhere Plugin for Eclipse.
Looks like you want to check out the files from TFS server to another(new workspace) instead of the old workspace(already mapped).
Then you need to remove the work folder mapping of your local path:
View the working folders for your Team Foundation Server workspace.
For more information, see View Team Foundation Server Workspaces and
the Working Folders.
In the Working folders list, right-click the row that corresponds to
the working folder mapping that you want to remove, and then click
Delete.
Repeat the previous step for any other mappings that you want to
remove, and then click OK.
Another way is through tf workfolder command from a command prompt
Type tf workfold -unmap LocalFolder, and then press ENTER. Replace LocalFolder with the path on your local computer that you mapped to that server folder. More information please refer this tutorial in MSDN.
If you don't need the old workspace any more, suggest you directly delete the old workspace in your develop machine. How to do this follow the answer in this question: How to remove a TFS Workspace Mapping?
I have downloaded a new version of eclipse, but now I can't open it because there is another version of eclipse attached to the workspace. I was thinking of deleting the older version but am scared of loosing work. Just wondering what I should do.
Delete the .metadata folder and import your project in your other version of Eclipse.
Make a save of this .metadata folder first just in case you need it
As suggested by #GPRathour download portable version of Eclipse & then import your existing projects into new environment. While doing this uncheck copy projects into workspace option. No need to delete existing. By doing this you can use both Eclipse.
Eclipse uses .metadata folder as well to store internal files and data structures. And many plugins store their settings in here to. Consider the content of this folder as a ‘black box’: so do not change it, do not touch it unless you really know what you are doing!
There is a lot of effort involved in configuring the checkstyle/findbug/codestyle etc in a workspace, so repeating the same for another workspace consumes a lot of time.
Is there any way in which I can simply export the preferences from one workspace to another in eclipse ?
They are stored in the .settings folder or in .files at the root of the project. You can commit thwm to you SCM. That would make the project know about the IDE, but that's not a problem if settings don't contain absolute paths.
Some (but unfortunately not all) of the settings you mention can be exported to and imported from an xml file.
I'm a student and have to work with Java and Eclipse. As we have teamprojects i have to sync my workspace with other students. The only problem i have is a folder called .metadata, right above my workspacefolder. Is there any possibility to change the path of this folder so that it won't be synced?
You can sync your project folder instead of the whole workspace.
If you want to share multiple projects you can put them in a sub-folder of your workspace and share only this sub-folder.
BTW, I recommend you using a real SCM like GIT or SVN that give you opportunity to ignore some file/directory.
I usually have multiple copies of a project, for example: a copy of the trunk and another of the last release branch. To cleanly separate my project files from Eclipse, they are checked out from Subversion in a directory outside the Eclipse workspace.
I want to make the project easily importable to Eclipse and followed instructions from multiple answers.
The problem is that my .launch files have the project name hardcoded. When a new project is imported, the launch files will display in the Run Configurations menu just if the project has exactly the same name of the exported one. This forbids me to have two versions of the same project.
It looks like the only way to do it is to have the .launch and .project files generated from an Ant task, but I don't see anyone using this solution. Maybe I should have multiple workspaces and the project always with the same name.
What's the best way to do it?
Edit: I'm marking VonC as the answer, but don't miss the comments.
Remember that the .launch configuration files don't have to be in your workspace.
They can be in your <project>/.settings as I mentioned in the answer you refer to.
That means you cannot import in your eclipse workspace two versions of the same project.
You need separate workspaces (not versioned themselves), each one referring to a project in a different path.
Each path represents different working trees (like different working directories for Subversion).
The OP adds:
The project must have the same name, but the project checkout dir can have any name.
To make the launch file work, you have to reference any file using the variable ${workspace_loc:ProjectName}.
Java files can be referenced using a path like: '/ProjectName/src/package/MyFile.java'
This way, it is easier to use any tool to interact with the subversion repository.
I want to make life easier for who uses Eclipse, but I don't want to force anyone to use it.
My recommendation is to tie the workspace to the checkout location, and then you can use the launch configurations for the relevant projects in Subversion.
My directory structure looks like this:
{checkout root}
|
+code
|
-workspace
In your case, that would mean a workspace for the trunk, and any other branch/tag you check out. I also keep all my projects outside the workspace. The workspace directory in Subversion is empty; I just recursively add the project reference(s) to the workspace from the sibling tree. It also helps if you export your Eclipse settings, as you can then re-import them into each new workspace.
I derived this approach from a pair of IBM and Rational white papers for using Eclipse with Rational ClearCase. This should work unless you need to have multiple versions of the same project open in the same workspace.