Community
Participate
Working Groups
When I checkout a working project folder from subversion, the source tree has ".svn" administrative folders throughout the tree. When I import the project into my workspace, or whenever I clean the project, the automatic build process ends up copying the .svn folders into the bin tree. If I run an update over the top-level project folder, subversion/TortoiseSVN gets confused and "restores" copies of source files into the bin tree. This led to much confusion until we figured out what was happening.
Are you using an Eclipse subversion plugin, such as subclipse (subclipse.tigris.org)? The plugin should handle these cases for you by marking the .svn folders as private folders that never appear in the UI.
I am not using subclipse or any similar eclipse plugin. The .svn folders don't ever appear in the UI anyway. The issue is that the .svn folders are being copied to the build output folders verbatim, and when a subversion client sees these verbatim copied folders - complete with base revisions of source files - it mistakes the bin folder for one in source control that should contain source files, and "restores" copies of source into the bin folder tree. These source files in the build folder are fairly innocuous, but created much confusion and worries about source safety and repository integrity before we figured out why precious source was in the disposable bin folder.
I understand what is happening... The Java builder does not know about subversion, or that those particular files will not be referenced by the compiled code, so it copies them to the output folder. You have a couple of options: 1) Use the subversion plugin. It will mark the .svn folders as special folders that the Java builder should not copy. 2) Define exclusion filters on your Java build path to indicate that those sub-folders should not be considered by the Java builder. Right-click on the project and select Properties > Java Build Path > Source, and edit the exclusion filters.
Marking invalid
