Mantis - ISSUES

0000339: File lock problem during commit on Mac

java.nio.channels.OverlappingFileLockException
java.nio.channels.OverlappingFileLockException
at
sun.nio.ch.FileChannelImpl$SharedFileLockTable.checkList(FileChannelImpl.java:1170)
at
sun.nio.ch.FileChannelImpl$SharedFileLockTable.add(FileChannelImpl.java:1072)
at sun.nio.ch.FileChannelImpl.lock(FileChannelImpl.java:834)
at
org.tmatesoft.svn.core.internal.io.fs.FSWriteLock.lock(FSWriteLock.java:120)
at
org.tmatesoft.svn.core.internal.io.fs.FSCommitter.commit(FSCommitter.java:456)
at
org.tmatesoft.svn.core.internal.io.fs.FSCommitter.commitTxn(FSCommitter.java:290)
at
org.tmatesoft.svn.core.internal.io.fs.FSCommitEditor.closeEdit(FSCommitEditor.java:361)
at
org.tmatesoft.svn.core.internal.wc.SVNCommitter.commit(SVNCommitter.java:366)
at
org.tmatesoft.svn.core.wc.SVNCommitClient.doCommit(SVNCommitClient.java:1004)
at
org.tmatesoft.svn.core.javahl.SVNClientImpl.commit(SVNClientImpl.java:767)

0000379: svnant checkout fails with authentication cancelled when trying to use svn+ssh with certificate-based authentication

I have an Ant target that I want to behave identically on both Windows XP and Solaris 5.10. I do development builds on Windows, but, the scheduled nightly build runs on Solaris.

Currently my build works fine on Windows, but fails in any svn target with "authentication cancelled" on Solaris. If I specify the svnant setting svnkit="false" then it works fine on Solaris, but fails on Windows.

I am sure I could solve the problem on Windows with svnkit="false" given time... but I would prefer to use svnkit="true", because it seems reasonable to me that a pure Java solution would be a better long-term bet for being able to keep my build working identically on both Windows and Solaris.

I had the exact same symptoms on Windows before I discovered the patch "trilead-ssh2-build213-svnkit-1.3-patch.jar". That patch completely resolved my problem on Windows, but, it seems to make no difference on Solaris, I get the same error with or without that file in my classpath.

I have configured certificate-based authentication so that when I use my SSH client I don't have to do any authentication. When I am at the command line on Solaris I can run svn commands against the repository with no manual authentication. When I use svnkit="false" the ant script can get to the repository with no manual authentication. But svnkit (on Solaris) cannot authenticate, even though the same version of svnkit authenticates fine from an ant script run on Windows.

0000351: Would like an option to act as if svnkit:charset=native is set on all text files

For use on z/OS where the default character encoding for text files is not ASCII or UTF-8, but EBCDIC, it would be convenient if I and my co-workers could set some configuration option to tell svnkit we'd like all text files treated as if svnkit:charset=native was set.

That way we could use svnkit to access other projects' repositories correctly, without having to clutter up those repositories setting svnkit-proprietary properties on files, which I suspect would not be appreciated.

0000375: Java heap space during check out

Problem happens during check out. Then I increased heap space from 256 to 512 Mb in Eclipse. When I observed checking out progress, OutOfMemoryError happened when I had about 200Mb free. Also when I switched to JavaHL it checked out successfully. Project which I checked out had many refactorings and it doesn't contain very big files.

java.lang.OutOfMemoryError: Java heap space
at com.sun.org.apache.xerces.internal.util.XMLStringBuffer.append(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.refresh(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLEntityScanner.invokeListeners(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLEntityScanner.peekChar(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source)
at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(Unknown Source)
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(Unknown Source)
at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.readData(HTTPConnection.java:754)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.readData(HTTPConnection.java:719)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPRequest.dispatch(HTTPRequest.java:216)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:349)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:275)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:263)
at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.doReport(DAVConnection.java:266)
at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.runReport(DAVRepository.java:1261)
at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.update(DAVRepository.java:818)
at org.tmatesoft.svn.core.wc.SVNUpdateClient.update(SVNUpdateClient.java:558)
at org.tmatesoft.svn.core.wc.SVNUpdateClient.doCheckout(SVNUpdateClient.java:914)
at org.tmatesoft.svn.core.javahl.SVNClientImpl.checkout(SVNClientImpl.java:2047)

0000378: Skipped message on out of date resources

Hi,

I am using the tigris subclipse eclipse plugin with svnkit.
Since upgrading to version 1.6.12 (which upgraded svnkit to 1.3.3 I guess), whenever I want to commit something that is out-of-date, I get a simple message:
Sending /dev/workspace/com.x.y.z
Skipped

This does not give any clue on why it was skipped, it took me some time the first time to figure out why it skipped and that an update fixed this.

Previous version showed in red (console view came to the foreground) a big error from the server that the resource was out-of-sync which was very informational.

When I use command-line svn I still get the full message:
svn: Commit failed (details follow):
svn: File or directory 'file.xml' is out of date; try updating
svn: resource out of date; try updating

I am seeing this on Linux, a co-worker sees the same on windows7 when he uses SVNKit with subclipse (it works fine when he uses javaHL).

Is this a change in 1.3.3 (I did not see anything related in the release notes)?

Is it possible to get more info on the reason for skipping the file?

This issue was first reported with subclipse where I was referred here:
http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=1047&dsMessageId=2630031 [^]

Thanks,

Rob

0000078: "Could not resolve hostname" when connecting through proxy

I am using subclipse with the JavaSVN library (installed subclipse plugins then installed JavaSVN plugins)

I have properly configured the proxy settings in Install/Update preferences page

When trying to open the repository http://svn-hosting.com/repository [^] I get SVN console shows

svn: PROPFIND request failed on '/snv/repository'
svn: PROPFIND of '/snv/repository': Could not resolve hostname `svn-hosting.com': No such host is known. (http://svn-hosting.com) [^]

On the contrary, no problems occur when I access the same url with my browser

I suspect that something is going on with the proxy discovery and/or tunneling but I do not know how to fix it.

Please assist

0000376: Handling of "301 Moved permanently" is wrong if path contains characters to be URL encoded

We think that we might ran into a problem with svnkit's handling of "301 Moved permanently". In method org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(String, String, HTTPHeader, InputStream, int, int, OutputStream, DefaultHandler, SVNErrorMessage) there is this code:

if (hostIndex > 0 && hostIndex < newLocation.length()) {
String newPath = newLocation.substring(hostIndex);
if (newPath.endsWith("/") &&
!newPath.endsWith("//") && !path.endsWith("/") &&
newPath.substring(0, newPath.length() - 1).equals(path)) {
path += "//";
continue;
}
}

This does not work if path contains characters which should be URL encoded: path contains unencoded characters, but newPath contains encoded characters and thus equals() fails.

0000377: Not correct statuses for svn externals

1. Set svn externals for file and folder by limiting them with revision, e.g.
-r 7403 http://localhost/repos/C.java [^] extC.java
-r 7497 http://localhost/repos/folder [^] ext_folder
2. Make any changes to file and folder after specified revisions and commit from another place
3. Call svn status command with contacting server side and as the result got that statuses contain incoming changes for previously specified externals despite that incoming changes revision is more than revision specified in externals, which is wrong, because, for instance, update command doesn't propogate changes shown by status command.

For testing, I tried the same with JavaHL 1.6.9 library and got only incoming statuses for external defined for file (which I think is wrong and I'll fire bug for SVN about it) but there are no incoming statuses defined for folder.

Tried with SVNKit 1.3.3.

0000374: ArrayIndexOutOfBoundsException during checkout

java.lang.ArrayIndexOutOfBoundsException: 0
at org.tmatesoft.svn.core.io.diff.SVNDiffWindow$InstructionsIterator.readNextInstruction(SVNDiffWindow.java:614)
at org.tmatesoft.svn.core.io.diff.SVNDiffWindow$InstructionsIterator.(SVNDiffWindow.java:582)
at org.tmatesoft.svn.core.io.diff.SVNDiffWindow.instructions(SVNDiffWindow.java:197)
at org.tmatesoft.svn.core.io.diff.SVNDiffWindow.apply(SVNDiffWindow.java:279)
at org.tmatesoft.svn.core.io.diff.SVNDeltaProcessor.textDeltaChunk(SVNDeltaProcessor.java:152)
at org.tmatesoft.svn.core.internal.wc.SVNUpdateEditor.textDeltaChunk(SVNUpdateEditor.java:1121)
at org.tmatesoft.svn.core.internal.wc.SVNCancellableEditor.textDeltaChunk(SVNCancellableEditor.java:124)
at org.tmatesoft.svn.core.internal.delta.SVNDeltaReader.nextWindow(SVNDeltaReader.java:143)
at org.tmatesoft.svn.core.internal.io.dav.handlers.BasicDAVDeltaHandler.characters(BasicDAVDeltaHandler.java:97)
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.characters(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanContent(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source)
at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(Unknown Source)
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(Unknown Source)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.readData(HTTPConnection.java:754)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.readData(HTTPConnection.java:719)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPRequest.dispatch(HTTPRequest.java:216)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:349)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:275)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:263)
at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.doReport(DAVConnection.java:266)
at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.runReport(DAVRepository.java:1261)
at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.update(DAVRepository.java:818)
at org.tmatesoft.svn.core.wc.SVNUpdateClient.update(SVNUpdateClient.java:558)
at org.tmatesoft.svn.core.wc.SVNUpdateClient.doCheckout(SVNUpdateClient.java:914)
at org.tmatesoft.svn.core.javahl.SVNClientImpl.checkout(SVNClientImpl.java:2047)

0000301: SSL handshaking failure in HTTPConnection results in infinite loop

The request method (to be exact, it's request(String method, String path, HTTPHeader header, InputStream body, int ok1, int ok2, OutputStream dst, DefaultHandler handler, SVNErrorMessage context) throws SVNException) has a big while(true) loop, and inside this loop is a catch block for SSLHandshakeException. I copied the code for your convenience below:

while(true) {
...
try {
...
} catch (SSLHandshakeException ssl) {
myRepository.getDebugLog().logFine(SVNLogType.NETWORK, ssl);
close();
if (ssl.getCause() instanceof SVNSSLUtil.CertificateNotTrustedException) {
SVNErrorManager.cancel(ssl.getCause().getMessage(), SVNLogType.NETWORK);
}
SVNErrorMessage sslErr = SVNErrorMessage.create(SVNErrorCode.RA_NOT_AUTHORIZED, "SSL handshake failed: ''{0}''", new Object[] { ssl.getMessage() }, SVNErrorMessage.TYPE_ERROR, ssl);
if (keyManager != null) {
keyManager.acknowledgeAndClearAuthentication(sslErr);
}
err = SVNErrorMessage.create(SVNErrorCode.RA_DAV_REQUEST_FAILED, ssl);
continue;
}

As you can see, in the end, this code just does "continue", which brings it back to the top of the while loop. Since the catch block doesn't seem to do anything that changes the outcome of the next attempt, it'll cause the same problem landing in the same catch clause, and causes the infinite loop.

And this catch block diligently computes the 'err' variable, which gets thrown away as soon as the next iteration of the while loop starts.

Is this a merge failure or something? The 'continue' statement aeppars out of place.

Or does this code really intend to retry the request? If so, I suggest some measure be added to avoid infinite loop.

0000373: Cannot create new file The filename, directory name, or volume label syntax is incorrect

happens on windows platforms.
svnkit spools files - the temporary path and file extensions use exceed the MAX_PATH setting on windows OS even if the original module path is moderate.

0000331: Exception Cannot read from 'C:\Users\bamboo\AppData\Roaming\Subversion\auth\svn.simple\c06ce622ee195a0f7777879507af2761'

svnkit throws the following exception
org.tmatesoft.svn.core.SVNException: svn: Cannot read from 'C:\Users\bamboo\AppData\Roaming\Subversion\auth\svn.simple\c06ce622ee195a0f7777879507af2761': C:\Users\bamboo\AppData\Roaming\Subversion\auth\svn.simple\c06ce622ee195a0f7777879507af2761 (Der Prozess kann nicht auf die Datei zugreifen, da sie von einem anderen Prozess verwendet wird)

>> cannot access because it is taken by another process

0000311: Actions hang 1024 seconds before they complete

0000371: NPE during update while checking tree conflict

0000372: NPE when resolving tree conflict

I haven't tried to reproduce the problem but anyway if NPE happens it's programmer error.

java.lang.NullPointerException
at org.tmatesoft.svn.core.internal.wc.admin.SVNWCAccess$TCEntryHandler.handleEntry(SVNWCAccess.java:826)
at org.tmatesoft.svn.core.internal.wc.admin.SVNWCAccess.walkEntries(SVNWCAccess.java:716)
at org.tmatesoft.svn.core.wc.SVNWCClient.doResolve(SVNWCClient.java:2105)
at org.tmatesoft.svn.core.wc.SVNWCClient.doResolve(SVNWCClient.java:1989)
at org.tmatesoft.svn.core.wc.SVNWCClient.doResolve(SVNWCClient.java:1948)
at org.tmatesoft.svn.core.javahl.SVNClientImpl.resolve(SVNClientImpl.java:950)

0000370: NPE during check out

java.lang.NullPointerException
at org.tmatesoft.svn.core.internal.io.svn.SVNReader.parseTuple(SVNReader.java:305)
at org.tmatesoft.svn.core.internal.io.svn.SVNReader.parseTuple(SVNReader.java:292)
at org.tmatesoft.svn.core.internal.io.svn.SVNEditModeReader.driveEditor(SVNEditModeReader.java:212)
at org.tmatesoft.svn.core.internal.io.svn.SVNRepositoryImpl.update(SVNRepositoryImpl.java:1487)
at org.tmatesoft.svn.core.wc.SVNUpdateClient.update(SVNUpdateClient.java:453)
at org.tmatesoft.svn.core.wc.SVNUpdateClient.doCheckout(SVNUpdateClient.java:855)
at org.tmatesoft.svn.core.javahl.SVNClientImpl.checkout(SVNClientImpl.java:2052)

0000368: SVNKit causes svnserve.exe to consume 99% CPU under Windows

We have a problem in our application where we sometimes see a CPU spike. We also see it during our integration tests. After a bit of investigation I've been able to nail down the reproduction scenario:
* single core Windows XP box
* get SVNKit to throw an exception. Our integration test tried to lock a file that was already locked. The small reproduction scenario I'll include with this bug tries to add a two-level deep directory to the repo.

SVNKit appears to complete its tasks and the program behaves as expected but the side effect of causing the CPU to spike is intolerable. I've reproduced this using both virtual machines and real hardware. Using a single CPU you can recreate the effect almost at will. Multi-core environments seem resistant to the bug. I also ran the test program under a single core Ubuntu VM and was unable to cause the spike, so it might be a Windows specific bug, but I'm just guessing. I watched SVNKit in the debugger and found that pausing will cause the problem to disappear. If you let it run all the way through without stopping at break points, you can see the problem There aren't many threads running so I'm not exactly sure what is going on.

I've attached an executable jar that prints some information about what it assumes and how to control it. Inside the jar is the source file to the class that can trigger the spike.

0000367: Cannot negotiate authentication mechanism with subversion server with NTLM authentication

From eclipse via svn protocol (svn://). [^] The subversion server have NTLM authentication. I get the follow error:
"svn: Cannot negotiate authentication mechanism"
Version svnkit: 1.3.0
Version Eclipse: Galileo 3.5

0000366: Large diffs with zero'ed file take inordinately long times (maybe forever)

We have a customer who has a large text file (in the order of 60 MBytes) which was then replaced with a file containing the same number of zero bytes. Attempting to diff the revisions causes svnkit to either hang or get memory exceptions.

You can see the diff between svn and jsvn operation in the additional information. I had to kill the jsvn run after about 2 hours. The process consumed 95% of one CPU for the duration.

The attached dump exhibits the problem (the test file is about 80M)

0000365: Checkout operations seem to be consistently almost twice as long as those in version 1.1.2

Have upgraded from version 1.1.2 to 1.3.2 and the checkout call seems to be up to twice as long as the old version. When executing:

public long checkout(SVNURL url,
SVNRevision revision, File destPath, boolean isRecursive)
throws SVNException {

SVNUpdateClient updateClient = ourClientManager.getUpdateClient();
/*
* sets externals not to be ignored during the checkout
*/
updateClient.setIgnoreExternals(false);

return updateClient.doCheckout(url, destPath, revision, revision, isRecursive);

However the following component is much faster so there has been tremendous progress there. Just cannot understand why the checkout takes so much longer than it used to.

repositoryURL = SVNURL.parseURIEncoded(projectRepositoryRoot + "/" + pullFile);
ourClientManager.getUpdateClient().doExport(repositoryURL,
wcDir, SVNRevision.parse(pullVersion),
SVNRevision.parse(pullVersion), "", true, false);

0000326: Setting properties twice fails

The method:

========================================================================
SVNWCClient.doSetProperty(SVNURL url, String propName, SVNPropertyValue propValue, SVNRevision baseRevision, String commitMessage, SVNProperties revisionProperties, boolean skipChecks, ISVNPropertyHandler handler)
========================================================================

can be called once. Next times it throws this exception:

org.tmatesoft.svn.core.SVNException : svn: No valid transaction supplied to closeEdit

0000271: SSL Client certificates with blank/no password dont work (Incompatibility with svn)

While I realize that having client certificates with blank passwords is not a good idea, the functionality does work with svn, tortoisesvn, etc.

I have a client certificate called nopassword.p12 and it was encoded with no export password. In my servers file the following do not work with svnkit/jsvn, but *do* work with svn or tortoisesvn.

[groupX]
ssl-client-cert-file = nopassword.p12
ssl-client-cert-password =

or

[groupX]
ssl-client-cert-file = nopassword.p12

but if I reencode the p12 from my pem file with an export password everything works

[groupX]
ssl-client-cert-file = withpassword.p12
ssl-client-cert-password = samplepassword

0000364: Commit operation is extremly slow, in eclipse

Commit operation can be extremely slow - one file every 30s or so. Windows reports that connection speed is ~50B/s.
It happens sometimes - looks like more eclipse is running more chance there is it will be slow. Most of the time restarting eclipse and trying commit again (after cleanup) makes it work normally.

Repository is on svn+ssh://, [^] and it is svn 1.5.3 on the server.

It never happens with 1.1.7 SVNKit connector.

Also, sometimes when trying to synchronize project, it reports that reply is malformed, trying to synchronize again works.

0000363: SVNKit 1.3.2 fails with "175002: RA layer request failed" during svn update where version 1.3.1 succeeds

SVNKit 1.3.2 can get in a bad state during svn update and stop communicating with the server. After a few update events SVNKit says connection refused although other svn clients have no issues whatsoever. This continues until SVNKit is reinitialized.

Reverting to SVNKit 1.3.1 resolves the issue.

Attaching log from failure with 1.3.2 and success with 1.3.1.

0000362: SVNKit dispatches an SVNEvent with null action

When the commit fails due to a lock, there is a strange SVNEvent dispached where getAction() returns null and the toString() method returns an empty String.

Is this intended behaviour?