Eclipse with Subclipse or Subversion

Note: I do not recommend using Eclipse with the Subclipse plugin, because for me it has exhibited numerous and frequent problems. Maintain your Subversion repository manually - the time spent doing this will be less than the time spent fixing problems created by Subclipse.

I have been using Subclipse 0.9.28 with Eclipse 3.0.2.

Workplace dialog after manual Subversion relocate | Go to top

If you use Subclipse to use Subversion with Eclipse and you manually relocate your working copies in your workplace (i.e. using the svn command from the command line), you'll also have to hack the Eclipse dialog setting file to reflect the new repository name.

In Linux, the dialog settings file is:

~/workspace/.metadata/.plugins/org.tigris.subversion.subclipse.ui/dialog_settings.xml

Change any instance of value="http://old/repos/location" to value="http://new/repos/location".

Subclipse incorrectly indicating local changes (or can't add resources to version control) | Go to top

If Subclipse is incorrectly indicating that you've made local changes (with the > symbol) and hence you need to commit - despite the fact that you've already done so - it could mean that some of the resources are not under version control.

If you have the option to add the resource to version control, via right-click -> Team -> Add to Version Control, then do so. If that option is greyed out, you could have a folder that's under version control which contains some resources that are not. This could cause particular problems if the unversioned resource is itself a folder which contains a versioned resource (don't ask me how this could happen, but it has done to me, on numerous occasions). To get around the problem you'll have to do one of the following:

  • Make a change to one of the versioned resources in the folder and then commit it. The dialog should ask you whether you want to add the other resources to version control. Note that I've not personally tested this. See this message on the Subclipse Users mailing list for more information: Re: [Subclipse-users] Add to Version Control issue.
  • Manually add the resources to version control. In a command prompt, cd into your workspace directory (normally at /home/username/workspace), then into the folder that contains the unversioned resources. Now follow Locked, Cleanup, Not a working copy for the solution.

Subclipse fails to commit after cross-project refactor | Go to top

After attempting to commit some changes after refactoring a class to move it into a new package in a different project, Subclipse failed with the following message: 

SVN Commit (Error: org.tigris.subversion.svnclientadapter.commandline.CmdLineException: svn: Commit failed (details follow):

svn: COPY of roundabout/common/ExpiryDate.java: 500 Internal Server Error (http://devbox.[company name].com)

)

Don't ask me what the trailing bracket is for - it always does that. The details of the error (i.e. stack trace) didn't reveal anything vaguely helpful.

I had two projects open, both under version control, but they were located at different places in the repository. I think this fact is what lead to the problem. I will call these projects project A and project B. This is what I'd done:

  1. Created a new package in project A. New -> Package. The new package was automatically flagged for addition to version control (it had a blue plus symbol next to it and showed as modified with the > symbol).
  2. Refactored some classes in project B to move them to the new package in project A. Refactor -> Move. The classes were moved, the references were updated and they were automatically flagged for addition to version control (see above).
  3. I attempted to commit the whole of project A. It failed with the above error message.

Inspecting the local copy revealed nothing out of the ordinary, but note the plus sign that indicates the resource is being added with history: 

steph@dimwit:workspace # svn status opencms-5.0.0-customised
?      opencms-5.0.0-customised/.classpath
?      opencms-5.0.0-customised/.project
?      opencms-5.0.0-customised/svn_log.txt
?      opencms-5.0.0-customised/bin
?      opencms-5.0.0-customised/META-INF/file
A      opencms-5.0.0-customised/java/com/opencms/roundabout/common
A  +   opencms-5.0.0-customised/java/com/opencms/roundabout/common/ModuleParameters.java
A  +   opencms-5.0.0-customised/java/com/opencms/roundabout/common/ExpiryDate.java

So, the problem is that Subclipse is attempting to copy between two different repositorys, which it obviously can't do. I think what's happening is that it moves the code in Eclipse, signals a Subversion COPY command and then deletes the original (not necessarily in that order). This means that when the COPY is attempted, Subversion can't find the original and fails. It would have nice if it had told you this before attempting it. Question: What shitty kind of program seems to do everything floorlessly and then fails when you attempt to save the changes? Answer: Subclipse.

Anyway, the only way I've found to fix the problem is to hack the .svn/entries file to tell Subversion not to copy but to do a normal add. This of course means you will loose any previous versioning info. 

<?xml version="1.0" encoding="utf-8"?>
<wc-entries
   xmlns="svn:">
<entry
   name=""
   url="http://devbox.[company name].com/svn/apps/trunk/cms/opencms-5.0.0/customised/java/com/opencms/roundabout/common"
   kind="dir"
   schedule="add"
   revision="0"/>
<entry
   name="ModuleParameters.java"
   copied="true"
   kind="file"
   copyfrom-rev="1047"
   schedule="add"
   prop-time="2006-07-20T13:19:50.000000Z"
   copyfrom-url="http://devbox.[company name].com/svn/repos/trunk/code/components/opencms/common/java/com/[company name]/roundabout/cms/common/ModuleParameters.java"/>
<entry
   name="ExpiryDate.java"
   copied="true"
   kind="file"
   copyfrom-rev="1047"
   schedule="add"
   prop-time="2006-07-20T13:23:30.000000Z"
   copyfrom-url="http://devbox.[company name].com/svn/repos/trunk/code/components/opencms/common/java/com/[company name]/roundabout/cms/common/ExpiryDate.java"/>
</wc-entries>

Becomes: 

<?xml version="1.0" encoding="utf-8"?>
<wc-entries
   xmlns="svn:">
<entry
   name=""
   url="http://devbox.[company name].com/svn/apps/trunk/cms/opencms-5.0.0/customised/java/com/opencms/roundabout/common"
   kind="dir"
   schedule="add"
   revision="0"/>
<entry
   name="ModuleParameters.java"
   kind="file"
   schedule="add"/>
<entry
   name="ExpiryDate.java"
   kind="file"
   schedule="add"/>
</wc-entries>

After modifying this file, Subversion reports that the addition will be without history: 

steph@dimwit:workspace # svn status opencms-5.0.0-customised
?      opencms-5.0.0-customised/.classpath
?      opencms-5.0.0-customised/.project
?      opencms-5.0.0-customised/svn_log.txt
?      opencms-5.0.0-customised/bin
?      opencms-5.0.0-customised/svn-commit.tmp
?      opencms-5.0.0-customised/META-INF/file
A      opencms-5.0.0-customised/java/com/opencms/roundabout/common
A      opencms-5.0.0-customised/java/com/opencms/roundabout/common/ModuleParameters.java
A      opencms-5.0.0-customised/java/com/opencms/roundabout/common/ExpiryDate.java

And the commit goes smoothly. Refresh the project in Eclipse and all will be ok. 

steph@dimwit:workspace # svn commit opencms-5.0.0-customised
Adding         opencms-5.0.0-customised/java/com/opencms/roundabout/common
Adding         opencms-5.0.0-customised/java/com/opencms/roundabout/common/ExpiryDate.java
Adding         opencms-5.0.0-customised/java/com/opencms/roundabout/common/ModuleParameters.java
Transmitting file data ......
Committed revision 167.

Last modified: 20/07/2006 (most likely earlier as a site migration in 2006 reset some dates) Tags: (none)

This website is a personal resource. Nothing here is guaranteed correct or complete, so use at your own risk and try not to delete the Internet. -Stephan

Site Info

mindspill.net © Stephan Dale.

Privacy policy

Go to top