The .metadata directory is in the directory of my workspace. Can I configure Eclipse so that the .metadata directory is not within the workspace?.
The reason is that we are many developers who use the same project directory and, if everyone starts its Eclipse instance on the same workspace, .metadata is modified by each developer.
As far as I know, there is no way to have the .metadata directory outside of the workspace directory. However, you can have your actual projects outside of your workspace directory!
For each developer, create a separate workspace, e.g. on that person's local hard drive. This workspace will hold that user's .metadata directory as well as references to the actual projects.
Import the projects from the "shared workspace" (which now no longer is an Eclipse workspace but an ordinary shared directory) into the individual workspaces using Import -> Existing Projects into Workspace. Uncheck the Copy Projects into Workspace checkbox!
This way, each developer has his own workspace, with individual settings etc., while the projects still reside in a shared directory. However, this can lead to serious troubles, as Eclipse will be unaware of other people editing files in the projects. Thus, this should only be used as a workaround in case 'proper' version control systems like SVN or Git are not an option.
You cannot configure the path of the .metadata directory.
The way you are trying to use Eclipse is only going to lead to grief for you and your team. Each workspace keeps track of whether it has seen the current revision of the file. If multiple people are editing the same project files, everyone on the team will have to constantly invoke refresh. There is also risk of loosing changes as one team member can easily and silently overwrite changes made by another.
Try harder to use a source control system. Centralized systems like SVN that need to be hosted somewhere aren't the only option. Systems like git, allow you safely swap changes directly between team members.
Related
"There are two options in vscode namely "Open Folder" and "Open WorkSpace". What is the difference between them? When should we use folder or workspace?
vscode --> WorkSpace
In workspace we have privilege to save our setting at the workspace level, not only this here you can open multiple folders in a workspace.If you want to do either of those things, use a workspace, otherwise, just open a folder.
In vscode there is list of project's folders and files.A workspace can contain multiple folders. You can customize the settings and preferences of a workspace.
A workspace is a folder, or multiple folders, mapped to areas in TFS. When code is checked out of TFS, the code is stored locally based off your workspace mappings. When you make changes to your code files, you are making those changes locally, to the files contained in your workspace.
One of the main reasons for workspaces is isolation. It provides a private sandbox where code changes can be made without having to worry if the changes will affect other team members. The changes remain in the local workspace until are checked into TFS.
TFS was designed to allow for one or more workspaces on the same machine. A single workspace can be created that contains multiple team projects and their code, or a more targeted workspace that only contains a particular project. There is no hard and fast rule for the best way to create workspaces. It will depend on personal preference, methodology, environment and the like.
Reference
vscode --> folder
When we want to work on single folder irrespective of their dependencies or in-dependencies and when we wants to opens a new instance of VS Code scoped to the selected folder OR to the folder containing the selected file.
Reference
The VSCode 1.53 (Jan. 2021) mentions the new article "What is a VS Code "workspace"?"
What is a VS Code "workspace"?
A Visual Studio Code "workspace" is the collection of one or more folders that are opened in a VS Code window (instance).
In most cases, you will have a single folder opened as the workspace but, depending on your development workflow, you can include more than one folder, using an advanced configuration called Multi-root workspaces.
The concept of a workspace enables VS Code to:
Configure settings that only apply to a specific folder or folders but not others.
Persist task and debugger launch configurations that are only valid in the context of that workspace.
Store and restore UI state associated with that workspace (for example, the files that are opened).
Selectively enable or disable extensions only for that workspace.
You may see the terms "folder" and "workspace" used interchangeably in VS Code documentation, issues, and community discussions.
Think of a workspace as the root of a project that has extra VS Code knowledge and capabilities.
Note: It is also possible to open VS Code without a workspace. For example, when you open a new VS Code window by selecting a file from your platform's File menu, you will not be inside a workspace. In this mode, some of VS Code's capabilities are reduced but you can still open text files and edit them
The same article adds:
What is the benefit of multi-root workspace over a folder?#
The most obvious advantage is that a multi-root workspace allows you to work with multiple projects that may not be stored inside the same parent folder on disk.
You can pick folders from anywhere to add to the workspace.
Even if you are mainly working in a single-folder-based project, you can benefit from using .code-workspace files.
You can store multiple .code-workspace files inside the folder to provide a scoped folder-view of certain aspects of the project depending on the scenario (for example client.code-workspace, server.code-workspace to filter out unrelated folders from the File Explorer).
Since .code-workspace files support relative paths for the folders section, these workspace files will work for everyone independent of where the folder is stored.
Finally, if for some projects you want to apply the same set of workspace settings or tasks/launch configurations, consider adding these into a .code-workspace file and add/remove these folders from that workspace.
Im very new to git ingeneral, egit and github.
The problem:
Lets say I have a project for eclipse in c:/username/workspace name "Test". So I versioned it and pushed it up to github.
Now I can see all my Files in github under the directory "Test" in github. In example /src. The "Test" directory is not versioned. only the name of the repository is "Test".
My next step was to delete my local files and fetch my project again(For testing). After that I had to import my project again (but I had to use the new project wizard) over the egit view. Unluckily also the wrong scala version was detected. (Was a play framework project). So I had a big exclamation mark on the project view.
My questions:
What is the best practice to oush a project to github so everyone can participate? Everything under the project folder? Obviously some information got lost through the process.
How can I prevent to generate a new project every time someone clones the repository?
What about best practices for using git inside the workspace. Eclipse warned not to put the project inside the workspace.
Im coming from a subversion background :/. Maybe a general missunderstanding.
Thanks in advance
Switching from SVN to Git in an Eclipse environment can take some getting use to. (I'm still getting accustomed to it myself.) Keep in mind the difference between the role of the .git folder and the .svn folders for Git and SVN respectively. There is a .svn folder at every folder level in the working copy. There is no .svn folder in the traditional Eclipse workspace root. The "source controlled things" are subdirectories of the workspace, not the workspace itself. This is generally good because the workspace contains desktop specific settings that one generally doesn't want shared (much of it in the .metadata directory).
With Git, there is only one .git folder that contains everything. The first impulse is to do a
git init
at the workspace level. This would make the subfolders (the Eclipse projects) eligible for source control. But wait, so is .metadata. Of course you can ignore it. But you may have to ignore lots of other folders (projects) that you do not want source controlled. Of course, the .gitignore should be included. But others will have different files to ignore.
It turns out that its easier to use Git with Eclipse if you place the .git folder and its sibling source controlled folders (Eclipse projects) someplace else besides the workspace root. Your view in Eclipse doesn't change. You still see all your projects, both the Git-controlled and the SVN controlled and ones not shared at all. But underneath in the filesystem, the Git-controlled folders will be somewhere else. This is what EGit prefers.
On my desktop, I have a workspaces directory for most of my Eclipse workspaces. Now that I use EGit, I also have an egit directory where I keep the local EGit repositories. The Eclipse workspaces that share using EGit reference a subdirectory of egit. It's from these local Git repositories that one pushes and pulls from GitHub.
Sorry for the length. I got a bit carried away.
I keep my .project and .classpath files in my source repository. I maintain separate eclipse workspaces for each branch off my trunk. I've found the best way to do this is to recursively copy my trunk workspace (cp -r dev/ branch-foo/). This works great. There are a few other details that facilitate sharing templates and key mappings, but that's not important here. The issue with this solution is that I end up with a workspace that, to no surprise, contains all the trunk projects. I then have to remove all these projects from the workspace manually and then import all the projects in the branch. Not a huge deal, but I'm wondering if something better can be done to automate this process.
I don't see any files that get written to as I add/remove project files in my workspace so I'm assuming eclipse manages these relationships in some internal DB or something. Additionally, I looked into any command-line support eclipse offers for doing this, but don't see anything.
Any thoughts would be much appreciated.
One P.S. - I do see some binary files located in ~/workspace/branch/.metadata/.plugins/org.eclipse.core.resources/.projects/project_name/
In my Eclipse workspace I've noticed the .metadata folder keeps growing. Should I regularly delete this folder? What would be the consequences of it?
Apart from that, what information does the .metadata folder contain?
Deleting all the .metadata folder would remove all your project references from your workspace.
If your project is actually stored completely in the workspace (i.e. its sources are stored in the default workspace path), you would also lose your project contents as well - which is worse since you wouldn't be able to re-import them.
I always recommend to keep your Eclipse project and its sources separate from the workspace.
See "What is "src" directory created by Eclipse?".
That way, the settings specific to your projects are saved within your project (in the .settings directory), and not in the workspace.
Also, you need to move your launcher definitions in your project as well.
In that configuration, you can delete a workspace without much damage and simply re-import your project into a new workspace.
I'm working on a new project with a full ANT build. I use eclipse to write my code, and I would like others to be able to check out the project to have a full working eclipse workspace. I do not want to have specific user settings committed though.
What files and directories should I have in source control?
(I'd rather not just go grab a plugin - I prefer more control over what goes in the repository)
We just put .project and .classpath in our repository, and that's sufficient to make it work "out of the box" for new developers. I'd like to have other stuff (run configurations come to mind), but haven't figured out how.
We use Subversion, so I put these files in a separate directory and defined svn:externals on that directory to point to the actual code, leaving it unpolluted by IDE-specific files.
Per request in the comments, here are the external that we use. Nothing complicated going on here:
Properties on 'svn://dev/trunk/IDEs/eclipse/runtime':
svn:ignore
bin
.fbprefs
cobertura.ser
.settings
svn:externals
lib/bin svn://dev/trunk/lib/bin
runtime svn://dev/trunk/runtime