Subversive, Exclamation Marks, and Copying Folders

I’ve had a reoccurring problem, and I’m blogging it for my memory’s sake.

The other day, I had an issue where a folder of mine was not being checked into Subversion via the Subversive plugin for Eclipse. The folder had an exclamation mark and refused to be committed. I couldn’t find any reference to what the exclamation mark meant. SVN cleanup didn’t work. On a lark, I started looking though the svn metadata in the .svn folder and saw that the metadata was pointing to the wrong repository. It then hit me what had happened.

I had started this project from scratch, but was grabbing files from other projects. I only grabbed only one folder, the folder containing the error handling templates; I just copied the folder via Eclipse from the original version controlled project to my new one. When you do this Eclipse copies not just the visible files but also the .svn metadata. Because of this when I went to commit Subversion could not reconcile that folder to the proper location and through errors.

  • To fix this:
    • delete the .svn subfolder in the folder in question and any subfolders
    • Then check in the folder again it should prompt you to add the files to the repository
  • To prevent this:
    • Don’t copy version controlled folders between projects in Eclipse
    • Create a mirrored folder structure
    • Copy files into new folder structure
  • A better way to prevent this:
    • Encapsulate and consolidate your code such that you don’t create the need to copy files between projects

Hope this helps someone else out there.

8 thoughts on “Subversive, Exclamation Marks, and Copying Folders

  1. Not sure if this will help anyone but I’m using Eclipse Helios with the Subversive plug and came upon this site while trying to find out what the red exclamation point at my project root was indicating. This explanation seemed to have merit, but I later found that the cause of the red exclamation point in my case was actually a missing jar that was referenced in the projects build path. Happy hunting 🙂

    Like

  2. This looks like a reasonable explanation. But I dont think this is an acceptable situation. The worst on this issue is that Java refactor like package rename or class move always breaks the SVN data structure. Older versions of Subeclipse did not suffer on this. That was the great fun of Eclipse+SVN: You had liberty to move/copy files anywhere anytime. Current Subversive is a long step backwards to times of CVS.

    Like

  3. Nice article.I cant believe I missed this blog for so long. Its just great stuff all round.I cant wait to read what you’ve got next. I love everything that youre saying and want more, more, MORE! Keep this up, man! Its just too good.

    Like

  4. Me too. Yesterday Subversive bit me rather badly when I used the Eclipse refactoring operation “move” to move a folder from a SVN project to a non-SVN project. It completely did the wrong thing; failed to execute the proper SVN command to delete the folder from the controlled workspace, and preserved the .svn subfolders in the copy it dropped in the non-controlled workspace. For the record I am using Eclipse Helios SR2 with Subversive 0.7.9.I20110207-1700. Sure the advice about not moving folders is sound, but this is adapting user behavior to buggy code, ugh. At the very least Subversive could put up a gosh-darned dialog to say “Hey buddy this operation will break your workspace do you really want to continue”? At this point I think the Eclipse project should revoke the “incubation” status and set it back to “raw”. Does anyone know if Subclipse suffers from the same problems??

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s