Scott Palmer <scott.palmer@2connected.org> wrote on 03/16/2006 09:37:43
AM:
> > I guess the main question is what would be triggering us to even be
> > looking at that folder? Is your entire workspace folder and
> > Subversion
> > working copy? There are known problems if that is the case.
>
> Well I'm not sure if I fully understand the question.. but I think
> the answer is yes.
> That is, there is a .svn folder that is a sibling of the .metadata
> folder, so my "workspace" folder is a working copy from that
> perspective. But I would have that this would be a very common
> case. My workspace has several related projects all of which are in
> subversion. I have grouped these projects in subversion so they have
> a common version-controlled parent folder. I checkout that parent
> folder to effectively create a space where I can make an Eclipse
> workspace. The .metadata folder is NOT in subversion and is
> explicitly ignored via svn:ignore as I mentioned.
>
> What are the known problems?
Mostly minor things like this one. They have not been a high priority
because this is not a common case and there is an easy workaround that
gives a better setup anyway.
> What should I do instead? It seems that I'm going to have to deal
> with some awkward messing around with my folder structure in
> subversion... I don't want that since it is working well for me and
> this particular issue doesn't appear to be causing any harm.
> Hopefully the "known problems" will be resolved with changes to
> Eclipse and/or Subclipse.
There is a very simple workaround to the situation. It is documented in
the help, I believe under Tips and Tricks. Basically, do the checkout of
your projects to some location. Then create an Eclipse workspace and use
the File -> Import Existing Projects into Workspace. This points the
workspace at the projects at the other location. In Eclipse 3.1+ the
projects are even auto-shared with Subclipse. This gives you the same end
result you were looking for but keeps the Eclipse workspace physically
separate from your working copy.
> That's what I find strange as well. Eclipse should of course know
> better than to treat the .metadata folder that it created and manages
> as a project resource of some sort.
In this case, I doubt it is an Eclipse problem at all. That message is
sent when we get a null IResource. Usually, that is because of case
issues. In this case, the null is perfectly valid it is just that
Subclipse has located this folder. It probably ran some Subversion API
that included it in the results it sent back to us.
> What sort of experiment might be useful to get some useful info about
> this .metadata "resource" problem? So far it seems the messgae can
> be safely ignored.. but it still bugs me :)
We have code to only send that message once per session, so it would
probably be hard to track down. You would have to keep closing and
opening Eclipse. We only send it once, because when you have the case
problem, you would be getting it once for every file in your workspace.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subclipse.tigris.org
For additional commands, e-mail: users-help@subclipse.tigris.org
Received on Thu Mar 16 15:49:20 2006