Subclipse Message

This is a message from Subclipse (SVN?): 

    Invalid filesystem path syntax
svn: Cannot replace a directory from within

That's the literal message. All of it. Ends in nothing.

Subclipse Purple/Blue Cylinder: Normal, Copied...and Switched

New Subclipse stuff I didn't know I didn't want to know: purple cylinder icon. Using the properties dialog, and clicking the 'Subversion' label, this seems to mean "Status: normal, switched, copied"; instead of what the yellow cylinder means: "Status: normal, copied". Now how did this happen? I just tried to clone a folder as usual. The files in that folder has these purple cylinders.

(And why does it show a spinning beachball just to pop up that Properties dialog? Does it fetch all the data before popping up the dialog? WT*?)

Googling for purple cylinder...I found this link, although it is referred to as 'blue'.

http://svn.haxx.se/subusers/archive-2007-06/0052.shtml

The meaning of the blue is simple - the affected resources is "switched",
i.e. the working copy is mixed and the blue file is from different branch
than its parent directory. 

So, clearly something went wrong during the clone (actually, I use 'rename' to clone). I remember an error popup (there is an error popup I'd say 30-50% of the time with Subclipse), but then the renamed/cloned folder showed up anyway, as it does in cases. 

Simple solution would be to delete and revert the children, right? Tried it, the purple/blue cylinders show up again! After a revert, how can the working copy be mixed?!?

Deleted the whole folder, reverted, still mixed. WT*? 

Do I dare commit it? First, let's make a screenshot. 

Now then. 

Ah, could commit, they are not changed. Odd. 

Ok, this is fun: just made a 'Synchronize' on the 'site' folder, and now there's question marks instead! Well, that makes a lot more sense; either the revert or something else fixed this, but Subclipse failed to notice. 

Tried to rename the folder into _lib again. As usual: 

But this time, I get the folder with blue cylinder too!

Let's see if they're really what they say they are...

Nope, this time, brining the Synchronize to bear didn't change the looks. And nothing else I tried.
Errors. Cleanup menu item gone.

So, this means Terminal. This is why I have files called "shell_in_this_dir.command" containing this code in strategic positions in the source tree:

cd $(dirname $0)
$SHELL 

And then "svn cleanup". Refresh, Subclipse icons back to question marks again.

--

Anyway, I think the unerlying problem here is that I am doing operations that svn or Subclipse does not support: making these changes inside a cloned folder. I'll have to commit the clone first.

--

Yes, worked better. So the point of this article... reduces to:

(*) screenshots of blue icons.
(*) always commit clones before starting moving folders around in them.


No wonder the revision numbers keep rising so fast, when you have to commit all the time to feel and/or be safe.

Tilded Target Folder

I think I finally grokked the following unexpected interaction between svn and Maven/Eclipse Workspace Resolution feature. First, a bash illustration:

bash-3.2$ svn stat
?       .classpath
?       .project
?       .settings
~       target

See the "~       target"? That is what I believe was the cause of a mysterious build problem. (The tilde is probably due to me changing from "svn:ignore *" inside target dir, to "svn:ignore target", after discovering that the former doesn't work well. Maybe more in other blog post.)

The symptom of the problem I've been having for a few hours can be demonstrated and summarized like this: 

No problem building in maven. 

Lots of errors in red in Eclipse, as if a Maven dependency is not resolved somehow. 

Turning off Workspace Resolution makes the errors go away. 

Conclusion: something is up with Workspace Resolution. 

Theory: 1) there is something wrong with the target directory; 2) workspace resolution uses a project's target directory for dependencies (perhaps just points to $dependee_project/target/classes on the classpath). 

But that seems crazy. Surely the build should care how SVN flags the target directory? But the coincidence is a bit too strong to ignore. 

--

Turns out that Eclipse clean + build fixed it. Don't know why.

But the target folder had a severe SVN weirdness...


Doing "svn update target" failed bizarrely: "svn: Unable to lock 'src'". Huh?

Finally it got unstuck, inside Eclipse: 

    E   .../target

    Updated to revision 23696.

    ===== File Statistics: =====

    Existing: 1

I've never seen this 'E', existing, before. I must've managed to set a svn:ignore on it, but it existed in the repo. Or something.

SVN Delete-Revert For Cleanup

In Subclipse, instead of the 'cleanup' command, simply delete and revert instead. If you don't have any uncommitted changes, of course. Works much better.