firstname.lastname@example.org wrote on 07/31/2006 01:59:53 PM:
> No. Import Exisiting Project looks for an Eclipse project, but as I have
> out what I want Eclipse to start working with is an existing directory
> checked-out from svn and local files as a Java project.
> Therefore I used File->New->Project...-> and then either Java Project or
> Java Project from existing Ant buildfile (which exists). Both options
> do create an Eclipse project from the existing directory but not
> that this directory was checked out with svn (since it and all subdirs
> contain .svn subdirs).
I did not think we supported that option, but I just tried it and it
worked fine. I had an existing Subversion working copy (that does not
have Eclipse project files in it). I did File -> New Project and selected
Java project. I then used the option to "Create project from existing
source" and pointed it at this working copy.
Eclipse created the .project and .classpath files in this location and
Subclipse automatically connected to it. I did not have to do anything.
> Also, share project is not possible because that option insists on
> checking in the project into a *new* location, i.e. the
> combination cannot already exist. So this is obviously for projects
> only that do not already exist in the repository.
If Share Project detects the ".svn" folder in the root of the project it
goes down a different path and instead just offers to connect the project
to Subclipse. One of the links I had sent you shows this.
> This documentation revealed the bug (this is most definitely one): you
> only import an existing svn-managed folder
> under one condition, according to the doc:
> "The only requirement is that your working copy has to also be a
> Eclipse project.".
> This is strange: why would I want to import something into Eclipse that
> already an Eclipse project.
The main issue is that Eclipse has an ability to create a project where
part of the files are in one physical location, and others are in another
location. Subclipse does not support this because the Subversion working
copy format does not and when we call the Subversion API's they will fail.
Based on my tests listed previously, the wording in the docs is not
entirely accurate as it appears you can also create a new project in an
existing source location. What you cannot do is pull in Subversion
managed folders into an existing project. Subclipse does not support
> Obviously, it is a bug of Subclipse not to recognize Subversion managed
> folders when the other way (the one
> I have described above) is chosen to create (truely create) an Eclipse
> project from an existing folder.
Subclipse does not get to just "run" and interrogate folders. Eclipse is
in control and it lets us do stuff at defined points in the process.
Eclipse 3.1 added a hook at project creation that lets us run code to
examine if it is a Subversion managed project. That is how we auto-hook
up projects. Team providers are only associated at the project level
within Eclipse and because the Subversion working copy format has a
specific structure to it, we only work and connect up when the project
folder itself is a valid working copy.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Mon Jul 31 20:21:57 2006