I'm sick of getting
This client is too old to work with working copy
whenever I come back to Eclipse after using an svn client newer than stone age to fix my working copies.
Is there a way to make Subclipse use a current Subversion client??
Install the latest version using this update site: http://subclipse.tigris.org/update_1.6.x . It works fine for me together with Tortoise.
The SVN client version for your version of Subclipse does not match that of some other tool you use, such as TortoiseSVN or the command line (see this thread).
Check also your JavaHL (the Java language binding for the Subversion API).
Related
I am trying to use a new version of Eclipse and connect to a SVN server.
I have found that neither Subversive and Subclipe is available to install.
Are they not supported or not recommended to use so only way to use Eclipse and SVN together is using an old version(like Oxygen) of Eclipse?
Update:
I could download Subclipse 4.3.3 and tried to install it directly but it shows the below message...
It turned out that for the new Eclipse versions, we don't need SVNKit Client Adapter.
I am not 100% sure but at least to me, I can use SVN(commit/update) without that.
I will leave this post for someone who uses new Eclipse versions and need to access SVN for old projects like it happened to me.
Here is it full error that I get in Eclipse Juno when I try to commit my project through SVN
appears to be part of a Subversion 1.7 or greater working copy. Please upgrade your Subversion client to use this working copy.
I don't understand why I get this since my SVN client version is the latest one. (2.0.3)!
From Subversion 1.1 to Subversion 1.6, the layout of the Subversion client working directory did not change. In revision 1.7, it changed, and in 1.8, it changed again. This has caused a lot of consternation in people who share a working directory with more than one Subversion client.
Both Subversive and Subclipse, the two main Subversion clients for Eclipse actually pass off the work of creating the Subversion working directory to either SVNKit or to JavaHL -- what are called the _SVN Connectors. It's these two SVN Connectors that must match the version of your working directory. Don't check Subversive or Subclipse's version. Check out the SVN Connector version.
If you go to your preferences, into Team->SVN, you will see a tab for the SVN Connector. Check the version of your SVN Connector (whether JavaHL or SVNKit), and make sure you're using the right version. In your case, it should be 1.7.
The most common reason to see this error is because you're using two different Subversion clients on the same working directory (which is officially not supported, but everyone does it anyway).
For example, are you using TortoiseSVN or the Subversion command line client, and also the Eclipse client on the same working directory, you naughty spawn?
Confession time: I do it all the time. I find there are times when it's just damn easier to use the command line client to do certain jobs rather than struggle with the Eclipse client. For example, I can do svn log and do a grep filter to quickly find the revision I want rather than going through Eclipse. If you do this type of stuff, make sure your Subversion clients are all on the same general version (1.6 vs. 1.7 vs. 1.8).
Okay, you're a good boy and don't use different Subversion clients on the same working copy. Now what happened? In that case, I suspect you accidentally changed the SVN Connector version without realizing it -- either through an update, or in the settings. You can have multiple SVN Connector versions at the same time, and I believe each project can have different ones too.
Again, check your SVN Connector version, and make sure it's correct.
I also got this error trying to run this command:
svn co http://subversion.<path to trunk>/<project name>/
from a command prompt. I wasn't in the workspace project directory, just the workspace directory. We had the correct version of 1.8, but because I was in the wrong directory, not the project directory, I got this same error as listed above.
For me the problem was that I copied & pasted a package from an Eclipse workspace with an older SVN client.
I didn't know that in the background, along with the package, a .svn directory was copied as well. So when I tried to commit it I got this error. Deleting the .svn directory solved the problem.
Use search before asking.
There is no Apache Subversion 2.x. Subversion 1.8 is the latest release so far. You use Subversive 2.x which should work with Subversion 1.7 and 1.8 working copies without any issues.
Make sure that you actually run the latest Subversive version,
Attempt upgrading your local working copy using svn upgrade command,
Try checking out a fresh working copy from a repository and see whether you get any errors.
For a long time my subversion client was working just fine, and I used it for a while out of sts, but one day sts crashed and I rolled back to eclipse for a while and during that time I used subclipse to update a project of mine. Now STS is up and running again, but for some reason now if I ever try to update or commit from sts I get the following error:
The path '{pathname}' appears to be part of a Subversion 1.7 or greater
working copy. Please upgrade your Subversion client to use this
working copy.
There is not actually an available update for subclipse and sts still recognizes the most recently installed subclipse from the dashboard. Any ideas on how to fix this one?
You should be able to install Subclipse 1.8.x in STS. The update site URL is:
http://subclipse.tigris.org/update_1.8.x
That release includes Subversion 1.7 client so you should be all set once you do this.
Subclipse the JavaHL library to do SVN connections. On Windows, if you have the most recent Subclipse it looks like you should automatically have that installed, but if not they have a variety of installation instructions (alas system dependent).
On Windows 7, I have been using Tortoise for Subversion. I am also using Eclipse plugin for Subversion. I am using both of them interchangeably for making commits or updates to the project files. But on another system, I have same setup, Tortoise doesn't recognize the folders/files as SVN which are checked out using Eclipse.
I wonder, how can I fix this?
My experiences with Eclipse Subversion plugins (Subclipse, Subversive) and other clients (command line client, Tortoise, RapidSVN) ranges from "just work" to "destroyed workspaces". One time, a simple svn info on a Eclipse workspace changed all the meta data in a way, that Eclipse lost the project's connection to SVN.
The disk layout format depends on the connector type and its version.
Mabye the best bet is to use JavaHL as the plugin connector because it uses the same native libraries as Tortoise and the command line client.
Currently my personal policy is to use only one kind of SVN client for a workspace.
More or less recently format of SVN working copy has changed. Could it be that Eclipse plugin and TortoiseSVN use different formats? The latest version of TortoiseSVN uses the new format, it may make sense to check this for Eclipse plugin.
Make sure both your Eclipse plugin (are you using Subclipse? Subversive? another plugin?) and TortoiseSVN are based on the same version of Subversion. Any time Subversion release a new veresion (for example, from 1.5 to 1.6, or 1.6 to 1.7) they tend to modify the svn working copy format in such a way it's not recognized by SVN clients based on older versions.
For example, see the 1.6 release notes for more information.
I'm using Subversive plugin in Ganymede, but after today's update it stopped working - it just doesn't see any valid svn connectors (I've already been using 1.2.0 dev version of SVNKit, instead of a stable one, because Subversive / Ganymede could not handle it; now it can't handle even the dev one). Any ideas how to make it work? Are subversive guys releasing a new version of their plugin / connectors soon?
I had a similar problem right after the update. It turned out that I had been getting the connectors (the base connector and both the SVNKit and JavaHL connectors) from the Polarion site that had "ganymede" in the URL. Instead, I should have been using the general URL.
Checking my current configuration, you should be using this update URL:
http://www.polarion.org/projects/subversive/download/eclipse/2.0/update-site/
The one I had been using, that should be deprecated if you are using it, is:
http://www.polarion.org/projects/subversive/download/eclipse/2.0/ganymede-site/
Note the difference. Once I changed that, I was able to download the 2.0.3 versions of the connectors, and Subversion again worked for me.
I'm using Subclipse in Ganymede successfully, maybe could you switch? I do recall having problems with SvnKit also, I'm using the JavaHL client.