When you want to share a project to subversion repository what need to be shared?
The whole project or only the source files of the project.
Are there items within a project you should not share?
Peter, That is really a question of semantics. You should put those file into your SVN repo that you wish to have version control over. All of your source code is a good start. Any control files your application requires should also be stored. If you plan on doing any Continuous Integration / Delivery, then all files that are required to build and run your application should be stored in the a repository. You do not have to store everything in the same place, nor does it have to be in the same projects but it should be stored somewhere.
If you have multiple developers working on the same project I would recommend you NOT store the .project .dbconnections files. These files are developer specific for PDSOE.
When using Subclipse in PDSOE, there are some files that are automatically not included (Eclipse control files). This can be a good thing or bad depending on your application.
Your point is noted. However, if I share .project, then it forces all developers to use the exact same project name. It also forces all developers to have the same natures and facets (they are stored in .project). Same with .dbconnections. This forces all developer to have the same local names and directory structure for their database connections. If you have local dbs, this can cause issues. There are advantages and disadvantages to storing the .project and .dbconnections. You have to weight them for your environment.
I think it is wise to export your setting and make that export available to developers in the event they need to restore, but forcing everyone to have the same names and directory structure is a bit rigid for my development style.
I do agree with .propath. That should always be the same or you can cause a massive mess during downstream builds
We store source only, none of the project settings, but we are very small, not many developers and we let them manage the environments.
Another factor, is that we support multiple versions of OE (10.2B and 11.6) This has caused some source control challenges. The source itself has pre-processors to handle the code parts, so we do not have separate trunks by OE version. However, the .assemblies varies between OE version, so that is an example of a file that is not versioned in source control.
We do store .resx and .wrx, in source control, but recently found we have .resx problems if a UI is modified in 11.6 then built with 10.2B. No compile errors, but at runtime, you have some problems loading the .resx data. For this reason, we have an informal rule to only modify UI with 10.2B, not 11.6. There might be a better way to handle this?