org.apache.subversion.javahl.ClientException: Unsupported working copy format
This message show up if your are trying to use Subclipse 1.7 client with a Subversion 1.8 working copy or Subclipse 1.6 client with a newer version working copy.
Even if older clients and servers inter-operate transparently with 1.8 servers and clients, when a working copy is upgraded to Subversion 1.8, Subclipse 1.6 and client can no longer be used on it.
You need to get a newer Subversion client but you already upgraded Subclipse
Here is the trick, if Tortoise follow the rule “Version 1.8.X means builts against Subversion 1.8.X”, Subclipse not. Why ?
Subclipse follows an odd/even release numbering convention.
The 1.7.x release stream of Subclipse was built against development builds of Subversion 1.7.
The release of Subversion 1.7.0 started the Subclipse 1.8.X release branch.
So if you tried to upgrade Subclipse with http://subclipse.tigris.org/update_1.8.x that will not work with Subversion 1.8.
What to do
To be simple :
Subclipse 1.4.x works with Subversion 1.5.x features and working copy.
Subclipse 1.6.x works with Subversion 1.6.x features and working copy.
Subclipse 1.8.x works with Subversion 1.7.x features and working copy.
Subclipse 1.10.x works with Subversion 1.8.x features and working copy.
So if you got this error with (format 31), use the check for upgrade option on your Eclipse and add this url
http://subclipse.tigris.org/update_1.10.x
If it’s another error with another working copy error, check the Subclipse version working with your Subversion version, and use the right upgrade url.
Subversion Working Copy Format
Here is a little more explanation about the Subversion working copy format number, from the source code itself.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 |
There is no format version 0; we started with 1. The bump to 2 introduced the ".svn-work" extension. For example, ".svn/props/foo" became ".svn/props/foo.svn-work". The bump to 3 introduced the entry attribute old-and-busted.c::ENTRIES_ATTR_ABSENT. The bump to 4 renamed the magic "svn:this_dir" entry name to "". == 1.0.x shipped with format 4 == 1.1.x shipped with format 4 == 1.2.x shipped with format 4 == 1.3.x shipped with format 4 The bump to 5 added support for replacing files with history (the "revert base"). This was introduced in 1.4.0, but buggy until 1.4.6. The bump to 6 introduced caching of property modification state and certain properties in the entries file. The bump to 7 changed the entries file format from XML to a custom text-based format. The bump to 8 placed wcprops in one file per directory (named upgrade.c::WCPROPS_ALL_DATA) == 1.4.x shipped with format 8 The bump to 9 added changelists, keep-local, and sticky depth (for selective/sparse checkouts) to each entry. == 1.5.x shipped with format 9 The bump to 10 added tree-conflicts, file externals and a different canonicalization of urls. == 1.6.x shipped with format 10 The bump to 11 cleared the has_props, has_prop_mods, cachable_props, and present_props values in the entries file. Older clients expect proper values for these fields. [...] The bump to 29 renamed the pristine files from '<SHA1>' to '<SHA1>.svn-base' and introduced the EXTERNALS store. Bumped in r1129286. == 1.7.x shipped with format 29 The bump to 30 switched the conflict storage to a skel inside conflict_data. Also clears some known invalid state. Bumped in r1387742. The bump to 31 added the inherited_props column in the NODES table. Bumped in r1395109. == 1.8.x shipped with format 31 |
Source : http://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_wc/wc.h
Hope this explain you the difference between TortoiseSVN and Subclipse version numbers and explain the format number in Subversion working copy
Thanks for the post. I upgraded my subversion client and ran into this issue. Even after deleting and re-importing maven projects, it wasn’t recognizing SVN connection - so no history available, no commit possible. After I upgraded my subclipse to 1.10, now it works!!
whew! thanks for summarising this information. Who’d have thought intuitively that you need Subclipse 10 for SVN 8; Subclipse 8 for SVN 7, etc… ?
Thanks for this valuable info
+1
thanks. This helped big time….