All,
I have a 20 member dev team working on a development project.
To provide greater control we have created a workspace with necessary projects and configurations (like project preferences, set-ups etc) in IBM RAD.
The idea is to have the pre-configured project in subversion so that when the dev team members checkout the project they get a complete workspace, so that they do not have to configure setups them selves.
However the problem is everytime someone checks out the workspace IBM RAD will also edit the .metadata (and some other folders and properties file) folder that has been checked in.
Idea is the developer should not have to change anything except the source code folders or application specific files.
I think many other teams might have faced situations like this.
Can anybody provide the best practices/process/references on how this is done in development projects?
Thanks
I think svn ignore will solve your problem.
check http://svnbook.red-bean.com/en/1.1/ch07s02.html
The svn:ignore property contains a
list of file patterns which certain
Subversion operations will ignore.
Perhaps the most commonly used special
property, it works in conjunction with
the global-ignores run-time
configuration option (see the section
called “Config”) to filter unversioned
files and directories out of commands
svn status, svn add, and svn import.
You cannot stop IBM RAD from updating .metadata folder and Eclipse doesn't support splitting workspace folder as it does for the configuration folder.
The best solution would be to setup your build scripts to be able to setup your workspace based on some .zip file(s), where you've captured the required settings for the workspace. This will give the closest thing to automatic workspace setup without having to deal constantly with changed files in .svn.
Related
Which Eclipse files is it appropriate to put under source control, aside from the sources obviously?
In my project, specifically, I'm wondering about:
.metadata/*
project-dir/.project
project-dir/.classpath
project-dir/.settings/*
If there are any of these for which it depends, please explain your guidelines.
Metadata should not be managed in source control. They contain mostly data relevant to your workspace.
The only exception is the .launch XML files (launcher definition).
They are found in
[eclipse-workspace]\.metadata\.plugins\org.eclipse.debug.core\.launches
And they should be copied into your project directory: When your project is refreshed, those configurations will be displayed in the "Run configuration" dialog.
That way, those launch parameter files can be also managed into the SCM.
(Warning: Do uncheck the option "Delete configurations when associated resource is deleted" in the Run/Launching/Launch Configuration preference panel: It is common to soft-delete a project in order to import it back again - to force a reinitialization of the eclipse metadata. But this option, if checked, will remove your detailed launch parameters!)
project-dir/.project
project-dir/.classpath
project-dir/.settings/*
should be in your SCM (especially .project and .classpath according to the Eclipse documentation).
The goal is that anyone can checkout/update his/her SCM workspace and import the Eclipse project into the Eclipse workspace.
For that, you want to use only relative paths in your .classpath, using linked resources.
Note: it is better if project-dir refers to an "external" project directory, not a directory created under the eclipse workspace. That way, the two notions (eclipse workspace vs. SCM workspace) are clearly separated.
As ipsquiggle mentions in the comment, and as I have alluded to in an old answer, you can actually save the launching configuration as shared file directly in your project directory. All launching configuration can then be versioned like the other project files.
(From the blog post Tip: Creating and Sharing Launch Configurations from KD)
I am currently working on a project where we have the .project and .cproject files under source control. The idea was that settings related to library paths and link directives would propagate across the team.
In practice it hasn't worked very well, merges almost always come back in a conflicted state which need to be deconflicted outside of eclipse and then the project closed and reopened for the changes to take effect.
I wouldn't recommend keeping them in source control.
It's worth nothing that CDT configuration files are not source-control-friendly. There's a bug filed for .cproject files changing very frequently and causing conflicts, see Sharing cdt-project files in repository always causes conflicts.
Some projects, like those using Maven, like to generate the .project files based on POMs.
That said, other than that - .metadata should NOT be in source control. Your project will have to make a determination about whether projectdir/.settings does, based on how you plan to manage standards and such. If you can honestly trust your developers to set up their environment based on the standard, and you don't have to customize anything special for any project, then you don't need to put them in. Me, I recommend configuring every project specifically. This allows devs to work on multiple projects' stuff in the same workspace without having to change default settings back and forth, and it makes the settings very explicit, overriding whatever their default settings are to match the project's standards.
Only difficult part is making sure they all stay in sync. But in most cases you can copy the .settings files from project to project. If there are any you specifically don't want in source control, do the equivalent of setting svn:ignore for them, if your SCM supports it.
The .classpath file is definitively a good candidate for checking into scm as setting it by hand can be a lot of work and will be difficult for new devs getting into the project. It is true it can be generated from other sources, in which case you would check in the other source.
As for .settings, it depends on the settings. This is a grey area, but some settings are almost mandatory and it is convenient to be able to check out a project, import it in Eclipse and have everything set up and good to go.
At our project, we therefore maintain a copy of the .settings folder called CVS.settings and we have an ant task to copy it to .settings. When you get the project from CVS, you call the 'eclipsify' ant task to copy the default settings to the new .settings folder. When you configure settings that are needed by everyone developing on the project, you merge those back into the CVS.settings folder and commit that to CVS. This way saving settings in SCM becomes a conscious process. It does require devs to merge those settings back into their .settings folders from time to time when big changes are checked in. But it's a simple system that works surprisingly well.
I'd say none of them. They most likely contain information that is relevant only to your workstation (I'm thinking about paths for libraries and all). Also what if someone in your team is not using Eclipse?
Consider:
.classpath
.project
.launch
These SHOULD be in version control as long as you stick to using project-relative paths. This allows other developers to check out the project and start working right away without having to go through all the setup pain that other developers went through as well.
You might be tempted to include .metadata in version control as well so Eclipse developers can check out an entire workspace and have it preconfigured with all the right projects, but it includes a lot of user specific information that anytime anybody works on it, it will change, so I would advise to NOT INCLUDE .metadata. It's easy to build a local workspace just by importing all existing Eclipse projects.
I have spent too many hours configuring eclipse workspace settings for new colleagues (and myself). What I ended up doing eventually was copying my own .metadata to the new developer machine.
If you are working on a team, then I think the following are very good candidates to keep under version control:
Installed JREs and their names
Server Runtime Environments
Java Editor Templates
Version Control Keyboard Shortcuts
Plugin settings that do not provide project specific settings
Maven settings
Preconfigured Perspectives
...
I haven't tried to put anything in .metadata under version control, but I'm using version control for these files for ten years now:
project-dir/.project
project-dir/.classpath
project-dir/.settings/*
The main reason is that Eclipse sometimes damages those files. Without version control, you will get weird and hard to track errors. With version control, you can immediately see "Why is it trying to deploy test classes???" or "Why is Maven and Eclipse using the same classpath?" (leading to https://bugs.eclipse.org/bugs/show_bug.cgi?id=430605).
With version control, you can see when it happens and easily go back to a working set of config files.
If you use m2e: You can import the project now with the fast "Import existing project" instead of the slow "Import Maven project".
The drawback of this approach is that Eclipse seems to randomly change some of those files. Most plugins keep them stable but some use HashMap instead of, say, LinkedHashMap so the order of elements changes all the time. This means there is an additional step when you commit: Check for any modified settings and handle them, first.
It also means that the whole team has to agree on some standards: Like which warnings should be enabled. It's interesting that many people see this as a additional problem - as if they weren't working together.
In my experience, it takes a couple of weeks until those files stabilize. Partly because you gradually learn how to tweak Eclipse, partly because people learn what not to touch. You can think of this as lost time or time spent to improve the quality of your work environment (like keeping your desk uncluttered).
There is a bonus advantage of the "Commit settings first": It gets people to commit more often and in smaller pieces (i.e. more like "one thought at a time" instead of "on feature at a time plus a thousand of other, unrelated things that I just happened to stumble upton ... what was I working on again?").
As a seasoned developer, I've come to prefer the "small commits" way of working; it's just easier to stay on track and you tend to sort your thoughts and changes into smaller, more manageable steps. This helps to reduce the level of complexity. Everyone can juggle with one ball, no one can juggle with 20.
PS: For certain setting files, I have unit tests to make sure known errors don't creep in like the "trying to deploy tests" in WTP. That helps in the initial phase "commit everything, I'm too busy" phase.
We want to share an eclipse Qt project via an SVN repository.
Of course we need to share the .pro file of Qt to be able to build the project.
The problem is, that without the project files you can not handle the project in eclipse but we cannot use the same as they contain local references.
Also it would be nice to use the Eclipse SVN plugin to manage this.
I already tried to check out the project and create a Qt project on Checkout but this overwrites the checked-out project file.
Any suggestion would be appreciated.
These are some lines from the .cproject file that are autogenerated, so I can not change the absolute paths:
<storageModule moduleId="org.eclipse.cdt.core.pathentry">
<pathentry base-path="/usr/include/qt4" include="" kind="inc" path="" system="true"/>
<pathentry base-path="/usr/include/qt4" include="QtWebKit" kind="inc" path="" system="true"/>
...
There are 2 rules for Subversion (independent of Eclipse, should be the same all the time):
If the tool will regenerate a file, and you don't have to change it:
==> don't check it in your version management (may it Subversion, Git, CVS, ...).
If the file contains parts that are manually changed by a user
==> it should be checked into version management.
If you have the second case (not clear from your question), you should try to change the paths to be relative, so that others could use your project at the same location.
If you cannot change that, stick to the location in the file system. Every developer has to use an identical setup.
If you have to support different operating systems, and the files generated by the tooling are not compliant (shame on the tool makers), you should hold templates for all operating systems in your version management, and should initially (manually) make a copy, depending on the operating system you are working in.
If you have to change that file for some purpose, you have to change the templates as well and should remember that all developers have to make a new copy after that.
Sorry, I don't know Qt and have never developed in a C-environment on different platforms, so my tips are pretty vague.
Finally I found following solution:
No .cproject .project file in SVN!
Import the code files from SVN (also the .pro file for Qt)
Eclipse will ask you to create a project, so create a Qt Project with the same name (or some else, but you will then have to delete the files)
When the project was created, revert it (right MB on the Project in Project Explorer -> Team -> Revert) to the state of the repo checkout
Done, now you can work with the project
I've been told that an Eclipse workspace is the equivalent of a Visual Studio solution. But I've also been told that people commonly use a single workspace for all their work. Are these apparently conflicting statements correct? If yes, how do we then create and maintain the equivalent of multiple VS solutions in Eclipse?
Secondly, in the case of VS, I check in my solution (.sln) files, too, into source control. Correspondingly, should I or should I not check in the Eclipse workspace's .metadata folder?
I don't think, the Eclipse workspace is equivalent to the VS solution. An Eclipse workspace stores a lot of meta-information about projects, their physical location (possibly in or outside of the workspace folder), etc., and even workbench settings. It is not a good idea to upload this information into source control, as it is possible that other developer uses other physical locations for the projects, etc.
There is a similar concept in Eclipse to the solutions (similar, not equivalent): Project sets. It is only a GUI option to group your projects into sets. These sets cannot be executed together, and is only visible in the Project navigator.
Another way is to create multiple workspace folders, and you can use them as an alternative to solutions. The drawback of this approach is, that if you customize the IDE (e.g. by using Preferences, or by defining source control locations), these customizations have to be made in every workspace. This issue can be handled using the Workspace Mechanic tool (I haven't tried it, but it can migrate these settings).
The main reason why it is better FOR ME to have a separate workspace for a single project is performance and lucidity. With many projects within one workspace, you'd have to close the other ones because of shared classpaths for editor assistance. Editor uses classpaths of all projects for content assist, class hierarchy lookup etc.
Eclipse anticipates that the open projects are related. And when using project managers like Maven, one maven project is usually divided into many little eclipse projects. It's simply a best practice to have a separate workspace for a project. Second reason is, that usually you'd need to import another related project to see how things are done and it would be terrible mess then having it all in one workspace.
You definitely shouldn't commit the .metadata folder into source control. You commit only the projects inside. Because you and others then will check out the project only into their own workspace. But it is a question whether you should commit the .project file, because it's personalized and eclipse version specific and things like project nature (java, spring, maven nature etc.) can anybody set up by himself. .classpath files in the project should be committed to the source control, because they specify classpaths, it would be very time consuming setting it up again.
You can either group your projects in different workspace or in a particular workspace. Non can be harmful once you manage your settings properly.
In eclipse you can create a new directory for a sub-project under the root project and add to the build path like so:
Does anyone know how Eclipse determines which projects are in a particular workspace? Is there a config file somewhere with this info? I have struggled (in vain) for several hours trying to figure this out. I'd like to be able to edit this config / check it into SVN...
I think Eclipse works much better if you manage just the individual projects in your version control system.
You can publish the set of projects that make up a workspace as a Project Set File (an XML file that can be created as Export > Team > Project Set), which you could put in your repository. This file contains the repository location for all projects, so that they can be checked out all at once.
I agree with Thilo that it is not a good idea to put the workspace metadata into your version control system.
However, in the spirit of answering the question and letting others make their own value decisions: The directory ${workspace_loc}/.metadata/.plugins/org.eclipse.core.resources/.projects should contain one directory for each project that eclipse uses to keep track of where the project is on disk and a whole bunch of other information.
Which Eclipse files is it appropriate to put under source control, aside from the sources obviously?
In my project, specifically, I'm wondering about:
.metadata/*
project-dir/.project
project-dir/.classpath
project-dir/.settings/*
If there are any of these for which it depends, please explain your guidelines.
Metadata should not be managed in source control. They contain mostly data relevant to your workspace.
The only exception is the .launch XML files (launcher definition).
They are found in
[eclipse-workspace]\.metadata\.plugins\org.eclipse.debug.core\.launches
And they should be copied into your project directory: When your project is refreshed, those configurations will be displayed in the "Run configuration" dialog.
That way, those launch parameter files can be also managed into the SCM.
(Warning: Do uncheck the option "Delete configurations when associated resource is deleted" in the Run/Launching/Launch Configuration preference panel: It is common to soft-delete a project in order to import it back again - to force a reinitialization of the eclipse metadata. But this option, if checked, will remove your detailed launch parameters!)
project-dir/.project
project-dir/.classpath
project-dir/.settings/*
should be in your SCM (especially .project and .classpath according to the Eclipse documentation).
The goal is that anyone can checkout/update his/her SCM workspace and import the Eclipse project into the Eclipse workspace.
For that, you want to use only relative paths in your .classpath, using linked resources.
Note: it is better if project-dir refers to an "external" project directory, not a directory created under the eclipse workspace. That way, the two notions (eclipse workspace vs. SCM workspace) are clearly separated.
As ipsquiggle mentions in the comment, and as I have alluded to in an old answer, you can actually save the launching configuration as shared file directly in your project directory. All launching configuration can then be versioned like the other project files.
(From the blog post Tip: Creating and Sharing Launch Configurations from KD)
I am currently working on a project where we have the .project and .cproject files under source control. The idea was that settings related to library paths and link directives would propagate across the team.
In practice it hasn't worked very well, merges almost always come back in a conflicted state which need to be deconflicted outside of eclipse and then the project closed and reopened for the changes to take effect.
I wouldn't recommend keeping them in source control.
It's worth nothing that CDT configuration files are not source-control-friendly. There's a bug filed for .cproject files changing very frequently and causing conflicts, see Sharing cdt-project files in repository always causes conflicts.
Some projects, like those using Maven, like to generate the .project files based on POMs.
That said, other than that - .metadata should NOT be in source control. Your project will have to make a determination about whether projectdir/.settings does, based on how you plan to manage standards and such. If you can honestly trust your developers to set up their environment based on the standard, and you don't have to customize anything special for any project, then you don't need to put them in. Me, I recommend configuring every project specifically. This allows devs to work on multiple projects' stuff in the same workspace without having to change default settings back and forth, and it makes the settings very explicit, overriding whatever their default settings are to match the project's standards.
Only difficult part is making sure they all stay in sync. But in most cases you can copy the .settings files from project to project. If there are any you specifically don't want in source control, do the equivalent of setting svn:ignore for them, if your SCM supports it.
The .classpath file is definitively a good candidate for checking into scm as setting it by hand can be a lot of work and will be difficult for new devs getting into the project. It is true it can be generated from other sources, in which case you would check in the other source.
As for .settings, it depends on the settings. This is a grey area, but some settings are almost mandatory and it is convenient to be able to check out a project, import it in Eclipse and have everything set up and good to go.
At our project, we therefore maintain a copy of the .settings folder called CVS.settings and we have an ant task to copy it to .settings. When you get the project from CVS, you call the 'eclipsify' ant task to copy the default settings to the new .settings folder. When you configure settings that are needed by everyone developing on the project, you merge those back into the CVS.settings folder and commit that to CVS. This way saving settings in SCM becomes a conscious process. It does require devs to merge those settings back into their .settings folders from time to time when big changes are checked in. But it's a simple system that works surprisingly well.
I'd say none of them. They most likely contain information that is relevant only to your workstation (I'm thinking about paths for libraries and all). Also what if someone in your team is not using Eclipse?
Consider:
.classpath
.project
.launch
These SHOULD be in version control as long as you stick to using project-relative paths. This allows other developers to check out the project and start working right away without having to go through all the setup pain that other developers went through as well.
You might be tempted to include .metadata in version control as well so Eclipse developers can check out an entire workspace and have it preconfigured with all the right projects, but it includes a lot of user specific information that anytime anybody works on it, it will change, so I would advise to NOT INCLUDE .metadata. It's easy to build a local workspace just by importing all existing Eclipse projects.
I have spent too many hours configuring eclipse workspace settings for new colleagues (and myself). What I ended up doing eventually was copying my own .metadata to the new developer machine.
If you are working on a team, then I think the following are very good candidates to keep under version control:
Installed JREs and their names
Server Runtime Environments
Java Editor Templates
Version Control Keyboard Shortcuts
Plugin settings that do not provide project specific settings
Maven settings
Preconfigured Perspectives
...
I haven't tried to put anything in .metadata under version control, but I'm using version control for these files for ten years now:
project-dir/.project
project-dir/.classpath
project-dir/.settings/*
The main reason is that Eclipse sometimes damages those files. Without version control, you will get weird and hard to track errors. With version control, you can immediately see "Why is it trying to deploy test classes???" or "Why is Maven and Eclipse using the same classpath?" (leading to https://bugs.eclipse.org/bugs/show_bug.cgi?id=430605).
With version control, you can see when it happens and easily go back to a working set of config files.
If you use m2e: You can import the project now with the fast "Import existing project" instead of the slow "Import Maven project".
The drawback of this approach is that Eclipse seems to randomly change some of those files. Most plugins keep them stable but some use HashMap instead of, say, LinkedHashMap so the order of elements changes all the time. This means there is an additional step when you commit: Check for any modified settings and handle them, first.
It also means that the whole team has to agree on some standards: Like which warnings should be enabled. It's interesting that many people see this as a additional problem - as if they weren't working together.
In my experience, it takes a couple of weeks until those files stabilize. Partly because you gradually learn how to tweak Eclipse, partly because people learn what not to touch. You can think of this as lost time or time spent to improve the quality of your work environment (like keeping your desk uncluttered).
There is a bonus advantage of the "Commit settings first": It gets people to commit more often and in smaller pieces (i.e. more like "one thought at a time" instead of "on feature at a time plus a thousand of other, unrelated things that I just happened to stumble upton ... what was I working on again?").
As a seasoned developer, I've come to prefer the "small commits" way of working; it's just easier to stay on track and you tend to sort your thoughts and changes into smaller, more manageable steps. This helps to reduce the level of complexity. Everyone can juggle with one ball, no one can juggle with 20.
PS: For certain setting files, I have unit tests to make sure known errors don't creep in like the "trying to deploy tests" in WTP. That helps in the initial phase "commit everything, I'm too busy" phase.