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
- detects working copy (WC) generation (pre-1.6 or after-1.7);
- chooses a corresponding runner;
- 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.