My problem is a little unique and I couldnt find the solution by googling it.
The first time I setup development environment on my machine, I did not use svn plugin in eclipse. I did an svn checkout under C directory. The files that get checked out have a lot of stuff (which are not specifically projects). However there are three projects somewhere inside the checkout (two are java projects and one is a web projects). I opened those three directories as projects in eclipse. Works perfectly fine. And I used to check in code by going to the directory and using check in option.
Now I installed the svn plugin and I want to link the eclipse projects directly to svn. I read at a few places that it can be done by Team->Share project. But I am afraid it might check-in the eclipse specific files (which might get me into trouble). Also there was a suggestion that if you uncheck "use default location" when creating a new project it will detect that the project is versioned. But the issue here is that the .svn hidden folder is only in the base directory of the checkout and not in every subdirectories. Hence that eclipse wont detect svn settings because the projects that I need to use are somewhere inside the folder structure of the entire checkout.
Not sure how to go around this. Please suggest a solution to this.
Actually, the ".svn" folder does not contain settings, it contains Subversion context, and there should be an .svn directory for each and every project directory that is under Subversion archiving.
The Eclipse .project and .classpath files may be safely archived in svn, and usually should. Although for best results, they should not contain absolute file paths. You can avoid this by defining symbolic pathnames. I do that so that Eclipse can find my Tomcat libraries, for example.
In theory, if you already have the .svn context is a project, Eclipse can be instructed to adopt that context, and yes, Team/Share is probably what would do it. Although for maximum safety, I'd get the Subversion administrator to make a backup of the Subversion archive and do this at a time when a botched attempt could be rolled back.
If that isn't possible, consider checking out a fresh copy of the project and manually merging in whatever changes you have made in your current project.
Also note that in SVN, the archive is presented as though it was a filesystem tree. This means that a "project" doesn't have to be one of the root directories of the archive, it can be any subdirectory. I checked one out just yesterday using a URL in the form of "https://subversion.mydomain.com/projects/projectxyz/branches/timh/branch1".
Customer surveys are for companies who didn't pay proper attention to begin with.
Personally, I would from the command line check in any changes that I made in that directory. Then in Eclipse I would check out the projects again in a different workspace/location, and continue my work from there. I have probably done this hundreds of times (if I did a survey at this time I would probably find that I have checked out a handful of projects in about half a dozen different locations) and have never run into an issue.
If you are not ready to check in your changes, then what I would do is check out the projects form Subversion into a new workspace/location and then use a file diff tool to merge the the changes (or simply copy the updated files if I'm sure no-one else changed them). I have probably done this 100s of times also.
Yes, doing the above is a little more work, and perhaps the client tools could handle the shuffling around of files and Subversion connections, but in the past I have been bitten too many times gy things that I though would work but didn't that now I'm probably over cautious. But it helps keep my stress level down. ;-)