In this post I’m using Subclipse. I am not too sure whether you’d have the same problem with Subversive or whether it can be fix in the same way. Also I am working on a Mac. Of course the actual solution to this problem is not Mac OS X specific but would also work with Linux. So if you are using Eclipse and Subversion, just ignore the Mac specifics (e.g. Homebrew) and keep reading.
I installed subversion 1.8 using Homebrew some time ago but Eclipse kept using the old svn version so I didn’t have to upgrade my working copies. Now I tried to update a working copy from the command line (it contains documents and not code. That’s why I didn’t do it in Eclipse) and saw that I hadn’t upgraded it yet:
$ svn up svn: E155036: Please see the 'svn upgrade' command svn: E155036: The working copy at '/Users/henribenoit/workspace/kanban' is too old (format 29) to work with client version '1.8.0 (r1490375)' (expects format 31). You need to upgrade the working copy first.
No big deal, I just upgraded all working copies:
$ svn upgrade
Now I could update them:
$ svn up Updating '.': At revision 303.
But now I couldn’t synchronize the working copies with the repository using Eclipse any more because eclipse was using the old svn version:
Problems reported while synchronizing SVNStatusSubscriber. 0 of 1 resources were synchronized.
An error occurred synchronizing /kanban: Error getting status for resource P/kanban org.apache.subversion.javahl.ClientException: svn: E155021: This client is too old to work with the working copy at
‘/Users/henribenoit/workspace/kanban’ (format ’31’).
Error getting status for resource P/kanban org.apache.subversion.javahl.ClientException: svn: E155021: This client is too old to work with the working copy at
‘/Users/henribenoit/workspace/kanban’ (format ’31’).
org.apache.subversion.javahl.ClientException: svn: E155021: This client is too old to work with the working copy at
‘/Users/henribenoit/workspace/kanban’ (format ’31’).
org.apache.subversion.javahl.ClientException: svn: E155021: This client is too old to work with the working copy at
‘/Users/henribenoit/workspace/kanban’ (format ’31’).
Actually I had already installed subversion 1.8 but I didn’t install it with the Java language bindings (which I did when I installed svn 1.7). So to get a clean system, I removed svn:
$ brew remove subversion Uninstalling /usr/local/Cellar/subversion/1.8.0...
And wanted to install it again with the java bindings and as universal binaries (with 32bits and 64bits support), but got an error message:
$ brew install --universal --java subversion Error: subversion dependency serf not installed with: --universal
So I had to remove serf so that it can be installed also as a universal binary:
$ brew remove serf Uninstalling /usr/local/Cellar/serf/1.2.1...
And after serf, came sqlite:
$ brew install --universal --java subversion Error: subversion dependency sqlite not installed with: --universal $ brew remove sqlite Uninstalling /usr/local/Cellar/sqlite/3.8.0...
Now I could install subversion but it didn’t manage to create all the links because some links were left over from an older installation:
$ brew install --universal --java subversion ==> Installing subversion dependency: sqlite ... ==> Installing subversion dependency: serf ... ==> Installing subversion ... Warning: Could not link subversion. Unlinking... Error: The `brew link` step did not complete successfully The formula built, but is not symlinked into /usr/local You can try again using `brew link subversion' Possible conflicting files are: ...
It’s easy to fix by using the –overwrite option with brew link:
$ brew link --overwrite subversion Linking /usr/local/Cellar/subversion/1.8.0... 108 symlinks created
Now svn 1.8 is installed properly (including the Java language binding for the Subversion API i.e. JavaHL). But when I tried in Eclipse to synchronize with an svn repository, I got the following error message:
Incompatible JavaHL library loaded. Subversion 1.7.x required.
This basically means that this version of JavaHL is not supported by the installed version of subclipse. In fact, the Subversion Wiki also gives you this info:
Subclipse Version | SVN/JavaHL Version |
1.10.x | 1.8.x |
1.8.x | 1.7.x |
1.6.x | 1.6.x |
1.4.x | 1.5.x |
1.2.x | 1.4.x |
1.0.x | 1.4.x |
You can check which version of Subclipse is installed in the “About Eclipse” menu item (click there on “Installation details” and search for Subclipse). If you see e.g. that Subclipse 1.8.1 is installed, the table tells you it will only work with svn 1.7. So we need a newer version of Subclipse. My first idea was to run an update in Eclipse. But it updated some other software but nothing related to subclipse. Then I notice that the update site I had used to install subclipse was: http://subclipse.tigris.org/update_1.8.x
This means that it will provide minor updates like 1.8.2, 1.8.3 and so on but no major update like the version 1.10.x that we need for svn 1.8. So I added a new update site for Subclipse 1.10.x: http://subclipse.tigris.org/update_1.10.x/
Then installed Sublipse 1.10.2 from this update site and after my sync with the svn repository was successful !
Thanx, well and completely documented. Resolved my own problem (‘t was the last step).
If you’re coming from svn 1.7, don’t forget to run team::upgrade first thing before any other actions.
(Also, all self-signed certificates need to be accepted again)
Excellent time saving – thanks. In my case followed just the last step to hook eclipse against http://subclipse.tigris.org/update_1.10.x/, and it was a done deal.