On Thu, 07 Apr 2005 14:25:55 -0400, Mark Phippard wrote:
[snip]
>
> I do not think this is necessarily a bug. What happens in Subclipse is it
> looks at the Project folder from your workspace, and runs a Subversion API
> to retrieve the status. If Subversion tells us the item is not versioned,
> then we go through the wizard to create a new project in Subversion. If
> it returns SVN info, then we let you hook it back up. It sounds like if
> that folder is a symlink to another folder, the API is not returning that
> info to us. We are not doing any fancy logic here, we are just asking
> Subversion if that folder is versioned.
>
> Is there any reason you need to use Symlinks for this. Eclipse has the
> ability to just work with projects in a different location and this all
> works fine with Subclipse. Just do Import -> Existing Project into
> Workspace, then point it at your project. Eclipse will then allow you to
> work with that project as if it were in your workspace, and when you do
> Team -> Share Project it should ask to hook it up automatically.
>
well, actually for one reason I just like having all the projects I'm
working on in one directory (as they are modules and components of a
bigger web project, it's easier to set CDPATH and work on them in one
directory)
And the project root itself has several symlinks pointing around in it
(common pieces among multiple installs etc..), but after manually
Resolving all of the symlinks (about 3 or 4), subclipse auto-magically
detected the project after closing and re-opening it.
Is there any reason why you don't resolve the symlinks in subclipse? Or at
least "CD" into the directory? as I just checked and if I trun
svn status PrintTicket from the main project dir (referencing the symlink)
it fails. but changing into the PrintTicket directory and running svn
status works fine.
I still feel this is worth looking into and resolving (and documenting in
the FAQ now that the issue has been found)
Received on Fri Apr 8 05:39:42 2005