I've just ported a C++ system from codeblocks to eclipse. I now wish to put the workspace under source code control. I don't know if I have set this up correctly. The directory structure looks like
toplevel
+--.metadata
+--very big file structure
+--project1
+--.project
+--.cproject
+--various cpp/h files
+--project2
+--.project
+--.cproject
+--various cpp/h files
What I would like is to be able to checkout everything on a different machine, start up eclipse, point it to the workspace and pick up all the projects. I know I have to keep the .project and .cproject files but what do I need to keep in .metadata or have I got the entire structure wrong?
Edit I found Where in an Eclipse workspace is the list of projects stored? which recommends .metadata/.plugins/org.eclipse.core.resources/.projects but there is a structure under each project folder containing .markers .indexes and properties.index. Do all these need to be kept? I had a bad experience with codeblocks where I kept the layout file and even though I finally deleted it, it was stuck in the source code control system forever.
I would discourage you from putting .metadata folder into source code repository. It is a very complex and large folder that contains internal plug-in data. It is very hard to keep it in the repository.
The recommended way is to store only the project folders (project1 and project2) in the repo along with .project, .cproject and .settings. You can then import them using subversion or git on any other machine.
Related
Every time I boot Eclipse I get the error "The project description file (.project) for my project is missing".
As other StackOverflow answers have show, this is easy enough to fix: delete package from Eclipse and import it again. However, if I close and reopen Eclipse the error will be back. I have not found a permanent solution yet.
I have my workspace in my Dropbox, but at some point I decided it was time to start using Git. I don't really get Git but they say you have to put the .project file in your .gitignore because it is computer specific.
This I feel is the origin of the problem, but if I don't do any git related activities (push, commit, etc.) I still get this error.
How do I fix this once and for all?
A .project is a Eclipse-specific file that tells Eclipse about how the project's struture is placed in the project's hierarchy.
It's normal for this file (and other Eclipse specific files) to not be committed because other people participating on the same project may use other IDEs of their choices (intellij, and so on), so the content committed in your VCS is 'neutral' for IDEs.
When you create a project from inside Eclipse, the .project file shall be created along. But when you import into Eclipse an existing project, there are ways to generate locally the .project , .classpath and other Eclipse-required files. Maven, Gradle and Ant are some examples of tools that do this.
Finally, I recommend to keep these files in .gitignore so the project's contents in VCS will remain neutral to IDEs. So you will not bother other people using other IDEs.
So, the steps are:
Check out the project
Generate the eclipse files using maven, ant or gradle. If your project already uses a tool such as these, thats nice
Check if the project is OK inside eclipse (compiling, no errors)
Add the newly generated eclipse files to .gitignore
commit and push the .gitignore.
.project is not machine-specific as long as everyone on your team has the plug-ins installed for that kind of project. .classpath might be if you don't do things right. This is your project, though, so commit your .project.
Keeping .classpath clean largely revolves around keeping machine-specific paths and references out of it:
Set the project's JRE using an Execution Environment. It is an indirect way of saying what version you need, then the IDE figures it out for that machine. The stored value defaults to using the name of your default Installed JRE in the preferences, which is very machine-specific.
Put the jar files you need into the project, or into another project that this one can refer to. They go into source control as well for the sake of repeatability, unless you're using a tool like Maven, in which case be specific about the version you require where ever you state that dependency and make sure the relevant M2E plug-ins are installed.
After I import my maven project to eclipse, it created eclipse project files in my maven project. How do I clear them out?
After your comment "if I dont clean the project files, how to I hand it over to someone else? If they dont use eclipse would they be appreciate all those extra files unrelated to the project?" I have understood your need.
The best way to achieve it is to use a version control system (VCS) like git, svn etc. and add inside your project tree a special file call .[VCSofYourChoice]ignore. For example for git this file would be .gitignore for svn it would be .svnignore.
Once you created this file you add rules to exclude files or directories you don't want to share on your version control system of your choice. To find the syntax to use google it with keywords ".[VCSofYourChoice]ignore syntax".
Eclipse and eventually every IDE create specific files, in order to save project structure and other internals. Some of them prompt you to select in which folder you want to save these files, for example IntelliJ, but I am sure eclipse as well. So you every time you use and IDE and you import a project, some files are going to be generated. The cleanest way is to 1) select to save them in a folder not related with the actual project, and as it already suggested do not commit them and add them in an ignore list, on your VCS of choice (e.g git)
Our team has just moved from Netbeans to IntelliJ 9 Ultimate and need to know what files/folders should typically be excluded from source control as they are not "workstation portable", i.e.: they reference paths that only exist on one user's computer.
As far as I can tell, IntelliJ wants to ignore most of the .idea project including
.idea/artifacts/*
.idea/inspectionProfiles/*
.idea/copyright/*
.idea/dataSources.ids
.idea/dataSources.xml
.idea/workspace.xml
However, it seems to want to check in the .iml files that exist in each module's root directory.
I originally checked in the entire .idea directory via the command line which is obviously not aware of what "should" be ignored by IDEA. Is the entire .idea directory typically ignored?
We have a FAQ article covering this question.
[The .idea] format is used by all the recent IDE versions by default.
Here is what you need to share:
All the files under .idea directory in the project root except the workspace.xml and tasks.xml files which store user specific settings
All the .iml module files that can be located in different module directories (applies to IntelliJ IDEA)
Be careful about sharing the following:
Android artifacts that produce a signed build (will contain keystore passwords)
In IDEA 13 and earlier dataSources.ids, datasources.xml can contain database passwords. IDEA 14 solves this problem.
You may consider not to share the following:
.iml files for the Gradle or Maven based projects, since these files will be generated on import
gradle.xml file, see this discussion
user dictionaries folder (to avoid conflicts if other developer has the same name)
XML files under .idea/libraries in case they are generated from Gradle or Maven project
.idea directory is a replacement for the old .ipr (Idea Project) file and if you want to share the project between users, then you need to share .idea folder (with the exceptions mentioned in the FAQ) and all the .iml files.
Refer to GitHub's JetBrains.gitignore file to always have an updated listing of which files to ignore.
Not an exact answer to the question, but there are sample .gitignore files available here, including one for JetBrains which includes IntelliJ.
You might find this post interesting: Merges on IntelliJ IDEA .IPR and .IWS files
It seems to conclude that you should add all files except for: workspace.xml, dataSources.xml, sqlDataSources.xml and dynamic.xml. The answer there is focusing on having files that do not change simply from opening the editor or making ide specific changes.
I'm using PHPStorm.
Here is an example snippet for your .gitignore
# Ignore the following 2 PHPStorm files only workspace and tasks file
**/.idea/workspace.xml
**/.idea/tasks.xml
All other files in the .idea directory should be committed to your repository.
e.g: (commit everything else in the .idea directory)
new file: .idea/.name
new file: .idea/encodings.xml
new file: .idea/framework.iml
...
Docs: How to manage projects under Version Control Systems
Here is what you need to share:
All the files under .idea directory in the project root except the workspace.xml and tasks.xml files which store user specific settings
All the .iml module files that can be located in different module directories (applies to IntelliJ IDEA)
So basically, commit everything except workspace.xml and tasks.xml.
Yes, I believe so. You can check the SVN configuration to see what's ignored and add anything that you think should be ignored.
IntelliJ now creates its own .gitignore file in the .idea folder so you can safely add it to repository.
I am the only developer on this project.
I would not add the complete workspace, but I would add the .classpath and .project files (as well as the source, of course) so that you can recreate the project if needbe.
I wouldn't commit the whole workspace. But it is worth exporting platform settings and checking them into source control (probably in a separate SCM project as they don't really belong to any individual project) if you've made several changes in case you need to import them into a new workspace.
Examples of these files are those settings for:
Java->Code Style->Formatter
Java->Code Style->Clean Up
Java->Code Style->Code Templates
General->Editors-Text Editors-Spelling-Dictionary
Any other preferences you've made extensive changes to that support import/export
You should check in the primary sources/resources for the project. As others have noted, for a typical project this includes the .project and .classpath files.
Depending on the type of project, I'd add the .settings folder from the project. This folder contains project-specific settings that override the platform preferences, and other project-specific settings. If those are essential to your project then I would add them.
No.
Files that are generated by the IDE or by a build process (binary files, documentation produced by a generator) should not be checked into source control. The only files that should be checked in are your source files and external libraries that your source files utilize.
You might also be interested in the answers to this question: What should NOT be under source control?
I would commit only the project(s) you are working on, as well as .classpath and .project files, and not the whole workspace itself.
Even if you are the only developer, avoid committing the .settings directory. You could switch to another version of Eclipse, or another installation with a different set of plugins, and when you checkout projects in the second installation the .settings directory will be different. Also the .metadata directory is bound to vary.
That said, attempt to use Maven so that the Eclipse .project and .classpath files can be generated without requiring them to be checked in.
I've played with the idea (with Subversion) of having a "MyProject_Eclipseproj" folder that only contains the the Eclipse project files and directories, with an svn:externals prop that pulls in all the "MyProject" files/directories.
So, the layout would be:
/repos/trunk/MyProject
/repos/trunk/MyProject/build.xml
/repos/trunk/MyProject/src
/repos/trunk/MyProject/src/com
/repos/trunk/MyProject/src/com/mypackage
/repos/trunk/MyProject/src/com/mypackage/MyClass.java
/repos/trunk/MyProject_Eclipse_34 <- external prop goes here
/repos/trunk/MyProject_Eclipse_34/.settings/
/repos/trunk/MyProject_Eclipse_34/.project
/repos/trunk/MyProject_Eclipse_34/.classpath
/repos/trunk/MyProject_Eclipse_35 <- external prop goes here
/repos/trunk/MyProject_Eclipse_35/.settings/
/repos/trunk/MyProject_Eclipse_35/.project
/repos/trunk/MyProject_Eclipse_35/.classpath
The MyProject folder would be pure code, no eclipse contaimination. The MyProject_Eclipse_Ver would contain Eclipse specific files, and pointers to pull in the code folders. You could also have specific folders for different Eclipse versions so each developer wouldn't be forced to upgrade if something changed in the .settings or .project file between versions.
I have created my ActionScript source files in a folder on a Mac (I normally use Windows), and somehow managed to make an Eclipse/FDT project that can see them.
I now need to move them into a svn checkout of an existing project to get them under source control.
I just can't work out how you do this without losing all references in the project.
I'm new to Eclipse and don't really understand any of the terminology (e.g. workspace). Does Eclipse have project files or are they all hidden? Can the project file be moved?
Help me stackoverflow, you're my only hope.
Update:
From the FDT Flash Explorer window I can only seem to be able to move files/folders within projects that exist. Should I create a new project in the place I want first?
Should I move them from within Eclipse or from the file system? Do I need to setup a new workspace afterwards?
The project folder has 2 hidden files: .project and .classpath that have all the info of the project. You just need to copy those files along with your project files.
For instance, you have a project folder in workspace/myproject/, and you want to add it to a checkout svn folder, you just need to copy the complete folder content to the checkout and then add all the files to the svn (including the project hidden ones) and finally commit.
From now on, when you checkout from that svn, you will have the eclipse project files, so all you need to do is create new project, and select the option that says that you already have a project folder with the source files (I'm not near an eclipse IDE to tell exactly the steps, but it's something like this). Eclipse will then import the project with all the settings you had previously defined.
I hope that this answers your question.
Try refactoring your project. Rightclick on the folder to move and then choose Refactor->Move. Don't know if this will solve your problem but it will try to change the references in all projects according to the move.