SVNKIT-554 - SvnMerge - command have not been found

I would like to add more reproduce information for the issue https://issues.tmatesoft.com/issue/SVNKIT-554

Which leads to this message when trying to merge :
Merge failed with log:
svn: E200007: Runner for ‘org.tmatesoft.svn.core.wc2.SvnMerge’ command have not been found; probably not yet implement in this API.
svn: E200007: Runner for ‘org.tmatesoft.svn.core.wc2.SvnMerge’ command have not been found; probably not yet implement in this API.

We were able to reproduce the bug on two recent installation of Eclipse when trying to perform an SVN merge, on a project connected to a svn+ssh remote server, using the CollabNet MergeImpl, only when checking the all eligible revisions option at the end of the merge process UI

  • (conf1) AdoptOpenJDK jdk8u275-b01 + Eclipse 4.18.0 + SVNKit 1.10.1
  • (conf2) AdoptOpenJDK jdk8u265-b01 + Eclipse 4.18.0 + SVNKit 1.8.12.3

(conf1)
org.tigris.subversion.clientadapter.svnkit.feature (1.8.12.3) “SVNKit Client Adapter”
org.tigris.subversion.clientadapter.svnkit (1.8.12.3) “SVNKit Client Adapter” [Active]
org.tigris.subversion.subclipse (4.3.3.202012181204) “SVN Team Provider Core”
org.tigris.subversion.subclipse.core (4.3.3.202012181204) “SVN Team Provider Core” [Active]
org.tigris.subversion.subclipse.graph.feature (4.2.0.1) “Subversion Revision Graph”
org.tigris.subversion.subclipse.graph (4.2.0.1) “Subversion Revision Graph” [Starting]
org.tmatesoft.svnkit (1.10.1.r10777) “SVNKit pure Java Subversion Library” [Active]

(conf2)
org.tigris.subversion.clientadapter.svnkit.feature (1.8.12.3) “SVNKit Client Adapter”
org.tigris.subversion.subclipse (4.3.0.201901172050) “SVN Team Provider Core”
org.tigris.subversion.subclipse.graph.feature (4.2.0.1) “Subversion Revision Graph”
org.tmatesoft.svnkit (1.8.12.r10533_v20160129_0158) “SVNKit pure Java Subversion Library”

Hello Olivier,
thanks for the feedback. May I ask you what’s your working copy version (.svn/format)? Was it created by SVNKit or SVN and if SVN: which version of SVN are you using?

Usually SVNKit matches commands (like ‘merge’) with runners (like ‘runner for merge for WC [working copies] <= 1.6’ or like ‘runner for merge WC >= 1.7’; for some operations there’s the 3rd kind of purely remote URL-URL operations [e.g. svn cp URL URL -mMessage], but to my knowledge ‘merge’ operation is not among them).

So if there’s no runner for an operation, an exception is thrown.

  • The working copy was created in Eclipse (therefore using SVNKit I suppose as this is the registered interface on both Eclipse workspace tested)
  • The working copy format version is 1.7 (12 in .svn/format file)
  • The server format file at the root of the repostory indicates “5” … that would be subversion 1.4 I suppose… (*)
  • The server is using subversion 1.8.10 (r1615264) (as returned by svnadmin or svnserve)

(*) Looking at that I guess it might explain the issue ? Maybe svnkit fails to work properly with very old repos ? We could probably schedule an layout update for this !

No, it’s a bad idea to upgrade your formats if you want to use SVNKit. SVNKit is always behind native SVN, it always supports older formats (since 1.4) but the opposite is not true. Sometimes native SVN introduces a new format, and there’s a period when SVNKit doesn’t support it (until we implement it in SVNKit).

Moreover, the server version doesn’t matter (unless you’re working using file:/// protocol — and I guess you aren’t). In case of file:/// protocol SVNKit accesses repository using filesystem and the same applies to it: sometimes native SVN introduces new incompatible and SVNKit is lagging behind it for a while. So I wouldn’t recommend you to upgrade formats.

Anyway, it was just a general advice, it is not relevant to the issue.

The relevant part of the stack trace is:

Caused by: SVNException: svn: E200007: Runner for 'org.tmatesoft.svn.core.wc2.SvnMerge' command have not been found; probably not yet implement in this API.
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64)
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51)
org.tmatesoft.svn.core.wc2.SvnOperationFactory.getImplementation(SvnOperationFactory.java:1375)
org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1224)
org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294)
org.tmatesoft.svn.core.javahl17.SVNClientImpl.merge(SVNClientImpl.java:812)

If you look at SvnOperationFactory#getImplementation

https://svn.svnkit.com/repos/svnkit/trunk/svnkit/src/main/java/org/tmatesoft/svn/core/wc2/SvnOperationFactory.java

you’ll see that it just

  1. detects working copy (WC) generation (pre-1.6 or after-1.7);
  2. chooses a corresponding runner;
  3. runs the runner (we don’t get here as the runner can’t be found for some reason)

The runners are registered inside SvnOperationFactory#registerRunners

        registerOperationRunner(SvnMerge.class, new SvnOldMerge()); // WC <= 1.6
        registerOperationRunner(SvnMerge.class, new SvnNgMergePegged()); // WC >= 1.7
        registerOperationRunner(SvnMerge.class, new SvnNgMergeReintegrate()); // WC >= 1.7
        registerOperationRunner(SvnMerge.class, new SvnNgMerge()); // WC >= 1.7

So I have the following ideas:

  • your working copy format generation is not detected correctly;
  • the runner for the operation is not registered for some reason (though I don’t understand how this could happen);
  • you run URL-URL operation, do you? (merge one URL to another URL instead of mering URL to WC). To my knowledge this is impossible, but my knowledge could become outdated.

Could I ask you to download ‘jsvn’ standalone utility from https://svnkit.com/download and run the same ‘jsvn merge’ command? Does it fail with the same error? If yes, could I ask you to edit its sources a bit and re-run to produce more information (I will tell you how)?

While writing the answer I’ve got one more idea. Here’s the runner for ‘merge’ command (SvnNgMerge):

    @Override
    public boolean isApplicable(SvnMerge operation, SvnWcGeneration wcGeneration) throws SVNException {
        return super.isApplicable(operation, wcGeneration) 
                && !operation.isReintegrate() 
                && operation.getSource() == null
                && operation.getRevisionRanges() == null
                && operation.getFirstSource() != null
                && operation.getSecondSource() != null;
    }

The operation.getRevisionRanges() == null condition means ‘automatic merge’ feature and we do not support it in SVNKit (patches are welcome!). The automatic merge is the merge without revisions specified and hence SVN deduces the revision numbers to merge automatically.

https://issues.tmatesoft.com/issue/SVNKIT-432

For example:

svn merge URL WC

is an automatic merge while

svn merge -rREV1:REV2 URL WC

is non-automatic merge.

So as a work-around I would propose you to specify revision numbers to merge. I have nearly zero experience with Eclipse, so I don’t know if it allows one to do that but if you can and do that, I think, that would work.

I run an automatic merge from URL to WC.

The command displayed in the svn Eclipse console just before the error occurs is this one
merge svn+ssh://svn.example.com/path/to/branch C:/path/to/wc

Running ‘jsvn merge’ with the same arguments leads to a perfectly working merge.

Looking a the stacktrace below, it might be a bug in Tigris subclipse (or eclipse itself ?), because it looks like JavaHL was tried, even though SVNKit has been explicitly specified as the SVN client in the Eclipse configuration.
What do you think ? If you confirm this diagnostic, I will probably fill a bug on the corresponding project

Here the complete stacktrace when the problem occurs :

!ENTRY org.tigris.subversion.subclipse.core 4 -6 2021-01-12 14:25:07.187
!MESSAGE org.apache.subversion.javahl.ClientException: svn: E200007: Runner for 'org.tmatesoft.svn.core.wc2.SvnMerge' command have not been found; probably not yet implement in this API.
!STACK 0
org.tigris.subversion.svnclientadapter.SVNClientException: org.apache.subversion.javahl.ClientException: svn: E200007: Runner for 'org.tmatesoft.svn.core.wc2.SvnMerge' command have not been found; probably not yet implement in this API.
	at org.tigris.subversion.svnclientadapter.javahl.AbstractJhlClientAdapter.merge(AbstractJhlClientAdapter.java:2336)
	at org.tigris.subversion.svnclientadapter.javahl.AbstractJhlClientAdapter.merge(AbstractJhlClientAdapter.java:2354)
	at com.collabnet.subversion.merge.MergeCommand.run(MergeCommand.java:106)
	at com.collabnet.subversion.merge.MergeOperation.execute(MergeOperation.java:120)
	at org.tigris.subversion.subclipse.ui.operations.SVNOperation.run(SVNOperation.java:88)
	at org.eclipse.team.internal.ui.actions.JobRunnableContext.run(JobRunnableContext.java:155)
	at org.eclipse.team.internal.ui.actions.JobRunnableContext$ResourceJob.runInWorkspace(JobRunnableContext.java:83)
	at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:42)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)
Caused by: org.apache.subversion.javahl.ClientException: svn: E200007: Runner for 'org.tmatesoft.svn.core.wc2.SvnMerge' command have not been found; probably not yet implement in this API.
	at org.apache.subversion.javahl.ClientException.fromException(ClientException.java:68)
	at org.tmatesoft.svn.core.javahl17.SVNClientImpl.getClientException(SVNClientImpl.java:1492)
	at org.tmatesoft.svn.core.javahl17.SVNClientImpl.merge(SVNClientImpl.java:814)
	at org.tigris.subversion.svnclientadapter.javahl.AbstractJhlClientAdapter.merge(AbstractJhlClientAdapter.java:2323)
	... 8 more
Caused by: org.tmatesoft.svn.core.SVNException: svn: E200007: Runner for 'org.tmatesoft.svn.core.wc2.SvnMerge' command have not been found; probably not yet implement in this API.
	at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64)
	at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51)
	at org.tmatesoft.svn.core.wc2.SvnOperationFactory.getImplementation(SvnOperationFactory.java:1375)
	at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1224)
	at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294)
	at org.tmatesoft.svn.core.javahl17.SVNClientImpl.merge(SVNClientImpl.java:812)
	... 9 more

I think, in ‘jsvn’ we have a work-around for no revisions specified (in SVNMergeCommand.java)

This is not a honest automatic merge but just a hack to make ‘jsvn merge’ not to fail all the time. If revisions are not specified ‘jsvn’ adds [1:PEG_REVISION] as range, where PEG_REVISION is either HEAD, or the explicit peg revision from the URL, or WORKING if merge source is local (not URL).

SVNKit implements JavaHL interface but it lacks ‘automatic merge’ feature as this feature is absent in the whole SVNKit. So formally speaking, it’s not subclipse bug SVNKit’s. I don’t know whether subclipse should implement SVNKit-specific work-around.

OK. Everything make sense now.

Then I think that, as long as SVNKit lacks the ‘automatic merge’ feature, it should not be proposed by the UI. I will ping CollabNet Desktop developers, so they hide the “All eligible versions” radio button option from their merge client, when the SVNKit client implementation as been selected.

I have submitted a new issue in the collabnet merge client :
https://ctf.open.collab.net/sf/tracker/do/viewArtifact/projects.desktop/tracker.backlog_item/artf12274

Thanks for you help @dmitry.pavlenko

The following answer was given by CollabNet developers

This plugin is just part of Subclipse now.

https://github.com/subclipse/subclipse

Based on what you wrote, it also cannot be fixed. Subclipse is written to JavaHL API. Support for SVNKit is only included based on its implementation of that API. So the only way for anything to get fixed is for the SVNKit library to fix it.

In general, I would recommend using JavaHL. You can followup the discussion at the Subclipse site.

Respond by visiting:
https://ctf.open.collab.net/sf/go/artf12274

An update: we’ve just released an SVNKit with a work-around for ‘automatic merge’. It’s not the honest ‘automatic merge’ implementation but the same work-around as used in ‘jsvn’ command line, so it should handle a majority of cases. So if subclipse update its dependency on SVNKit, merge should work.

Alternatively, you could try to substitute svnkit.jar somewhere as all SVNKit versions are forward and backward compatible.

1 Like

Thank you @dmitry.pavlenko.

Your efforts to fix this issue are really appreciated !