After doing a fresh checkout using Subversive, some of the directories retrieved because of svn:external properties are showing up as obstructed. However not all of them are. A command-line use of "svn status" properly shows all the directories as externals with no obstructions.
Why is this happening?
This does looks like this thread
We checked the situation and we had found that the problem can happen in case if working copy is locked by external process in time of update.
For example, the process TSVNCache that related to TortoiseSVN time-to-time produces conflicts with working copy access and JavaSVN library cannot complete working copy modification in correct way. As result working copy goes into "Obstructed" state, i.e. it is damaged.
The same diagnosis related to any process which locks working copy in time of working copy meta-data modification. (We found same behavior for MS Visual Studio 2005 Express Edition, but I don't know why the Studio locks WC?)
So be sure to make the checkout with the least possible number of application running.
Another source of conflict could be:
The SVN 1.4.x-compatible clients are automatically converts working copy into 1.4.x-compatible format. At the current moment Subversive Default client is incompatible with SVN 1.4.x working copy format.
So, if you performed any modification of the working copy using command line SVN client in your case you will get "Obstructed" state indicated over the resources in the workspace tree.
In order to resolve the problem I will propose you to switch SVN client option and select SVN Kit 1.1.0-based client or Native JavaHL 1.4.2 client.
Next, if resources already decorated as "Obstructed", please close and then open again corresponding projects or simply restart Eclipse IDE in order to reload SVN meta-information cache.
Now : the exact version may not be the same for you, but that is another lead to check.