MantisBT - Issues

0000415: SVNRepository.log(..) - SVNLogEntryPath objects should indicate property changes

Wed, 18 May 2011 01:46:45 +0400

Other SVN clients are capable of reporting property changes (versus content changes) on both directories and files during a typical "log" command. It would be nice if SVNKit offered the same capabilities.

0000311: Actions hang 1024 seconds before they complete

Wed, 18 May 2011 00:12:59 +0400

On occasion the action (check-in or update) that I perform hangs for 1024 seconds before it completes successfully. During that time it is not possible to cancel the action.
I have only observed this behavior when working with svn+ssh.

I looked into SVNKit code and found the reason of the problem:
SVNKit uses trilead library for SSH and to check connection status it calls following method from trilead
com.trilead.ssh2.channel.ChannelManager.waitForChannelRequestResult(ChannelManager.java:179) which calls 'wait' on Channel. But as SVNKit's thread is in waiting state it can't handle cancel event.

This is a pseudo-code I use to run operations:
Startup another thread which listens to cancel action, e.g. from UI, and which calls cancel action:
if (need to cancel) {
SVNClientEx client = ...;
client.cancelOperation();
}

Call commit operation:
SVNClientEx client = ...
client.commit(...);

Here are relevant stracktraces:
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x00007fd35513b128> (a com.trilead.ssh2.channel.Channel)
at java.lang.Object.wait(Object.java:502)
at com.trilead.ssh2.channel.ChannelManager.waitForChannelRequestResult(ChannelManager.java:179)
- locked <0x00007fd35513b128> (a com.trilead.ssh2.channel.Channel)
at com.trilead.ssh2.channel.ChannelManager.requestChannelTrileadPing(ChannelManager.java:634)
at com.trilead.ssh2.Session.ping(Session.java:324)
at org.tmatesoft.svn.core.internal.io.svn.SVNSSHConnector.isStale(SVNSSHConnector.java:225)
at org.tmatesoft.svn.core.internal.io.svn.SVNConnection.isConnectionStale(SVNConnection.java:328)
at org.tmatesoft.svn.core.internal.io.svn.SVNRepositoryImpl.openConnection(SVNRepositoryImpl.java:1222)
at org.tmatesoft.svn.core.internal.io.svn.SVNRepositoryImpl.setLocation(SVNRepositoryImpl.java:124)
at org.tmatesoft.svn.core.wc.DefaultSVNRepositoryPool.createRepository(DefaultSVNRepositoryPool.java:217)
- locked <0x00007fd3522fa1b8> (a org.tmatesoft.svn.core.wc.DefaultSVNRepositoryPool)
at org.tmatesoft.svn.core.wc.SVNClientManager.createRepository(SVNClientManager.java:251)
at org.tmatesoft.svn.core.wc.SVNBasicClient.createRepository(SVNBasicClient.java:335)
at org.tmatesoft.svn.core.wc.SVNBasicClient.createRepository(SVNBasicClient.java:327)
at org.tmatesoft.svn.core.wc.SVNCommitClient.doCommit(SVNCommitClient.java:991)
at org.tmatesoft.svn.core.javahl.SVNClientImpl.commit(SVNClientImpl.java:767)

0000414: OverlappingFileLockException in SQLJet

Sun, 15 May 2011 23:09:08 +0400

Hi Alex,

we have recieved an interesting bug report (https://bugs.eclipse.org/bugs/show_bug.cgi?id=345853 [^]), hope it will help to find the issue:

I'm using the Zend Development Editor (ZDE) 8.0 and recnetly had this bug report while trying to use my local subversion repository (file format version 4 (1.6)).

SVN/1.6.11 SVNKit/1.3.3 (http://svnkit.com/ [^]) r6649

JVM Properties:
{java.runtime.name=Java™ SE Runtime Environment, java.runtime.version=1.6.0_18-b07, java.vendor=Sun Microsystems Inc., line.separator=
, java.class.version=50.0, os.name=Windows 7, os.arch=x86, user.country=CA, os.version=6.1, eclipse.commands=-os win32 -ws win32 -arch x86 -showsplash -launcher C:\Program Files (x86)\Zend\Zend Studio – 8.0.0\ZendStudio.exe -name Zend Studio --launcher.library C:\Program Files (x86)\Zend\Zend Studio – 8.0.0\plugins/org.eclipse.equinox.launcher.win32.win32.x86_1.1.1.R36x_v20100810\eclipse_1309.dll -startup C:\Program Files (x86)\Zend\Zend Studio – 8.0.0\plugins/org.eclipse.equinox.launcher_1.1.0.v20100507.jar -showlocation -vm C:\Program Files (x86)\Zend\Zend Studio – 8.0.0\jre\bin\client\jvm.dll , java.version=1.6.0_18, osgi.framework.version=3.6.1.R36x_v20100806, file.separator=\, java.vm.info=mixed mode, path.separator=;, user.timezone=America/New_York, user.language=fr, java.vm.name=Java HotSpot™ Client VM, file.encoding=Cp1252}

java.nio.channels.OverlappingFileLockException
at sun.nio.ch.FileChannelImpl$SharedFileLockTable.checkList(Unknown Source)
at sun.nio.ch.FileChannelImpl$SharedFileLockTable.add(Unknown Source)
at sun.nio.ch.FileChannelImpl.tryLock(Unknown Source)
at org.tmatesoft.sqljet.core.internal.fs.SqlJetFileLockManager$1.createLock(SqlJetFileLockManager.java:75)
at org.tmatesoft.sqljet.core.internal.fs.SqlJetFileLockManager.createLock(SqlJetFileLockManager.java:60)
at org.tmatesoft.sqljet.core.internal.fs.SqlJetFileLockManager.tryLock(SqlJetFileLockManager.java:73)
at org.tmatesoft.sqljet.core.internal.fs.SqlJetFile.lock(SqlJetFile.java:485)
at org.tmatesoft.sqljet.core.internal.pager.SqlJetPager.waitOnLock(SqlJetPager.java:2513)
at org.tmatesoft.sqljet.core.internal.pager.SqlJetPager.sharedLock(SqlJetPager.java:1233)
at org.tmatesoft.sqljet.core.internal.pager.SqlJetPager.acquirePage(SqlJetPager.java:1019)
at org.tmatesoft.sqljet.core.internal.btree.SqlJetBtree.getMeta(SqlJetBtree.java:2148)
at org.tmatesoft.sqljet.core.internal.table.SqlJetOptions.verifySchemaVersion(SqlJetOptions.java:267)
at org.tmatesoft.sqljet.core.table.SqlJetDb.refreshSchema(SqlJetDb.java:649)
at org.tmatesoft.sqljet.core.table.SqlJetDb$7.runWithLock(SqlJetDb.java:440)
at org.tmatesoft.sqljet.core.table.SqlJetDb.runWithLock(SqlJetDb.java:305)
at org.tmatesoft.sqljet.core.table.SqlJetDb.beginTransaction(SqlJetDb.java:438)
at org.tmatesoft.sqljet.core.table.SqlJetDb$6.runWithLock(SqlJetDb.java:402)
at org.tmatesoft.sqljet.core.table.SqlJetDb.runWithLock(SqlJetDb.java:305)
at org.tmatesoft.sqljet.core.table.SqlJetDb.runTransaction(SqlJetDb.java:393)
at org.tmatesoft.sqljet.core.table.SqlJetDb.runReadTransaction(SqlJetDb.java:379)
at org.tmatesoft.svn.core.internal.io.fs.repcache.FSRepresentationCacheManager.runReadTransaction(FSRepresentationCacheManager.java:218)
at org.tmatesoft.svn.core.internal.io.fs.FSOutputStream.close(FSOutputStream.java:242)
at org.tmatesoft.svn.core.internal.wc.SVNFileUtil.closeFile(SVNFileUtil.java:1553)
at org.tmatesoft.svn.core.io.diff.SVNDiffWindowApplyBaton.close(SVNDiffWindowApplyBaton.java:103)
at org.tmatesoft.svn.core.io.diff.SVNDeltaProcessor.textDeltaEnd(SVNDeltaProcessor.java:174)
at org.tmatesoft.svn.core.internal.io.fs.FSDeltaConsumer.textDeltaEnd(FSDeltaConsumer.java:141)
at org.tmatesoft.svn.core.internal.io.fs.FSCommitEditor.textDeltaEnd(FSCommitEditor.java:293)
at org.tmatesoft.svn.core.io.diff.SVNDeltaGenerator.sendDelta(SVNDeltaGenerator.java:192)
at org.tmatesoft.svn.core.internal.wc.SVNCommitter.sendTextDeltas(SVNCommitter.java:266)
at org.tmatesoft.svn.core.internal.wc.SVNCommitter.commit(SVNCommitter.java:367)
at org.tmatesoft.svn.core.wc.SVNCommitClient.doCommit(SVNCommitClient.java:1009)
at org.tmatesoft.svn.core.javahl.SVNClientImpl.commit(SVNClientImpl.java:767)

0000412: FSRepositoryUtil.copy is static and synchronized

Thu, 12 May 2011 13:41:10 +0400

This is related to issue 369.

The method FSRepositoryUtil.copy is both static and synchronized. In an application with concurrent calls to FSRepository.getFile, all access is serialized. This is really bad in two cases:

a) an application is reading files from 2 different repositories in 2 different threads, but because of this lock only one file can be read at a time; this results in a loss of performance (and usability) in the application

b) an application is providing a multi-threaded service that publishes svn files, but all clients end up having serialized access; this results in clients ultimately timing out as they wait for all previous clients to finish their transactions, regardless of the server resources

This can be solved by removing the synchronization on this static method. The discussion for issue 369 mentioned that ourCopyBuffer was the resource being protected. A thread-local buffer or collection of cached buffers would give you similar memory/garbage-collection performance and remove the single-thread bottleneck. Alternatively, the signature could be altered to accept the copy buffer as an argument.

This single-threading makes it impossible to use svnkit for my application which serves data from several svn repositories to a number of clients.

0000413: The open connection code uses a global lock for connecting to any server and not a lock per server

Fri, 06 May 2011 14:26:14 +0400

When opening a connection, if there is any issue or timeout or deadlock with establishing the SSH connection for SVN+SSH protocol, then all connections even to other servers are blocked indefinitely.

We have seen this in the Jenkins project whereby occasionally a Subversion server will have issues with connecting and this causes all SVN polling to deadlock.

It makes sense to have a lock on establishing connections, but the lock should be limited to establishing connections to the same server and port and not a global lock.

The attached file is a Maven Project with two test cases.

The first test case should always pass to show that it is faking out a SVN+SSH server correctly
The second test case will pass when this issue is resolved. It starts two threads, the first connecting to a server that stalls completing the connection, and the second that tries to connect to a completely different server.

0000411: SVNSocketFactory: ISVNCanceller is never null

Mon, 02 May 2011 20:20:01 +0400

In relation to Bug 381 ( http://svnkit.com/tracker/view.php?id=381 [^] ),

In the class org.tmatesoft.svn.core.internal.util.SVNSocketFactory , the method connect test for whichever the object ISVNCanceller cancel is null to determine if thread should be use.

However, this condition can NEVER be true, therefor, leaving the application to open thread for each connection.

Backtracking the code, all call are point toward myRepository.getCanceller() .

return myCanceller == null ? ISVNCanceller.NULL : myCanceller;

Therefor, myCanceller can never be null, as if the canceller is null, ISVNCanceller.NULL, an empty instance of ISVNCanceller, is returned instead.

While bug 381 suggest a threadpool to improve performance, fixing SVNSocketFactory to support proper null canceller should also be planned.

Until a fix is released, we're using a patched version of this class for our project to improve performance. The patch is attached.

Hopefully, this could be added to version 1.3.6

0000391: please deploy svnkit-cli project to Maven repo

Sat, 16 Apr 2011 20:46:51 +0400

It would be awesome if svnkit-cli was provided alongside svnkit, i.e. please also publish org.tmatesoft.svnkit:svnkit-cli, not just org.tmatesoft.svnkit:svnkit

This would really help me in my Groovy scripts, when I want to @Grab svnkit-cli for quick use.

0000402: svn: Handshake failed, received : '...' or '( success ( 2 2 ( ) ( edit...'

Fri, 08 Apr 2011 21:21:43 +0400

I'm using SVN kit 1.3.5 connector for subversive and I get random exceptions "SVNException: svn: Handshake failed, received..." when updating or synchronizing with subversion.

I use svnssh+

The client is running on Windows 7.

The SVN server is on Ubuntu Server 10.10
SVN is 1.6.12
OpenSSH version is 5.5p1-4ubuntu5

Find in attachment the full stack trace for the two errors I encounter

0000410: the path returned from the SVNPathUtil.append(String,String) does not have the same semantics as arguments

Thu, 07 Apr 2011 15:10:57 +0400

If the SVNKit is used to access the DAV repository, the DAVRepository.doGetFullPath(String) method uses the SVNPathUtil.append(String,String) method to construct the full path.

If doGetFullPath's arguments ends with '/' character, that character will be removed by the SVNPathUtil.append method and the returned full path in some cases will not have the expected semantics.

Other SVNRepository implementations are probably affected too.

In my case:
The user code (org.codehaus.mojo.wagon.shared.WagonDirectoryScanner) checks if a string denotes a directory by adding trailing '/' to the resource name and asking Wagon.resourseExists().

The SWNWagon calls SVNRepository.checkPath and checks the kind of the returned SVNNodeKind to determine whether the resource exists or not.

The problem is that due to the usage of SVNPathUtil.append() inside SVNRepository implementations the two following calls will yeld the same result:
1) SVNRepository.checkPath( "/some.file")
2) SVNRepository.checkPath( "/some.file/")

Both calls will return SVNNodeKind.FILE, while the second call is expected to return the SVNNodeKind.NONE, or, in the rare cases when it is possible to have a file and a directory with the same name, the SVNNodeKind.DIR if "/some.file/" does exists as a directory in addition to the regualar "/some.file" file.

Regardles of whether the usage pattern of WagonDirectoryScanner+Wagon is not very good by itself, the SVNRepository.checkPath( "/some.file" ) and SVNRepository.checkPath( "/some.file/" ) must not return the same value.

On the same note - what's with that horrible SVNPathUtil.append implementation?
The same functionality (but already without removing the trailing '/'), but in the much clearer form:

append(f,s){
f = f == null ? "" : f;
s = s == null ? "" : s;
if ( f.endsWith("/") ) {
return f + s;
} else {
return f + '/' + s;
}
}

0000409: Server advertising SPNEGO auth results in SVNKit dying with SecurityException

Wed, 30 Mar 2011 19:14:45 +0400

This problem happens when all of the following conditions are met:

1. the repository is accessed via WebDAV
2. the server returns 401 and advertises SPNEGO auth (among others)
3. the SVNKit client not particularly configured for Kerberos auth

Here's how the problem occurs.

- The server gives us multiple WWW-Authenticate headers, so that the client can choose what it understands. The order just so happens to have SPNEGO before other authentication methods
- HTTPAuthentication.parseAuthParameters tries to convert this into an HTTPAuthentication object. Unless explicitly set, there's no sorting that takes place, so it'll go with SPNEGO, and you get an HTTPNegotiateAuthentication object returned from this method.
- negoAuth.needsLogin() gets called, which results in unchecked SecurityException. See the call stack below for the exact call sequence leading up to this.

The problem here is two-folds.

- Error message is cryptic. This is primarily a JRE's problem, but SVNKit can mitigate the problem by catching SecurityException and telling what this error is about.
- Most Java deployments are simply not properly configured to participate in SPNEGO authentication. AIU, it takes some dedicated configuration at JRE level, and very few people care to do that. So just because the server advertises SPNEGO, and just because SVNKit has code doesn't necessarily mean that you can actually do SPNEGO. A much better failure mode in this case is "svn: authentication cancelled", which happens when you don't have a matching credential.

I'm not exactly sure how to fix this, and I don't even know if you need a suggestion on that, but if I were doing it, I'd add a method on HTTPNegotiateAuthentication to check if the client has some credential configured, and if not, have HTTPAuthentication.parseAuthParameters tries the next available authentication method.

----
java.lang.SecurityException: Unable to locate a login configuration
at com.sun.security.auth.login.ConfigFile.(Unknown Source)
at sun.reflect.GeneratedConstructorAccessor73.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at java.lang.Class.newInstance0(Unknown Source)
at java.lang.Class.newInstance(Unknown Source)
at javax.security.auth.login.Configuration$3.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.login.Configuration.getConfiguration(Unknown Source)
at javax.security.auth.login.LoginContext$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.login.LoginContext.init(Unknown Source)
at javax.security.auth.login.LoginContext.(Unknown Source)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPNegotiateAuthentication.initializeSubject(HTTPNegotiateAuthentication.java:139)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPNegotiateAuthentication.needsLogin(HTTPNegotiateAuthentication.java:241)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:535)
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.exchangeCapabilities(DAVConnection.java:516)
at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:98)
at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1001)
at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.testConnection(DAVRepository.java:97)

0000408: doLock fails silently when a lock could not be taken

Wed, 30 Mar 2011 19:14:37 +0400

Hi,

I was trying to lock a file in a working copy that was not updated to current HEAD. SVNWCClient.doLock returns without an error, but does not actually take a lock - this means that after every doLock I have to check whether I actually have the lock through SVNWCClient.doInfo.getLock (where I think it is not entirely trivial to reliably determine that the lock is actually associated with the local working copy?)

I think it would be preferable if doLock raised an exception whenever it doesn't succeed in obtaining the lock for the local WC.

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

Thu, 24 Mar 2011 17:42:54 +0300

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.

0000404: Exception due to race condition when using svn+ssh

Tue, 15 Mar 2011 13:31:30 +0300

Original report:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=337151 [^]

Running the latest build of Subversive (0.7.9.I20101203-1700), I frequently
encounter this error while trying to synchronize, commit, or update. The error
log includes the following output (but no stack trace):

ERROR [0006] : Resolution attempt ended with exception:
java.io.IOException: svn: Malformed network data
ERROR java.io.IOException: svn: Malformed network data
ERROR java.io.IOException: svn: Handshake failed, received:

The error goes away after reverting to the previous version
(0.7.9.I20100512-1900). This is happening on every machine to which we have
installed Subversive. The problem is intermittent, but occurs frequently
enough that we generally can't successfully synchronize more than two or three
projects at a time.

1) svn, version 1.6.6 (r40053)
2) svn+ssh
3) we have a proxy for accessing external addresses only
4) we use the standard openssh-server from ubuntu Version: 1:5.3p1-3ubuntu5
5) the server is on our local area network. if we use the debugger and drop to
stack when the IOException occurs, the problem appears to go away while
stepping through the code, so this is likely due to a race condition.
6) We see the error on Eclipse clients and on our Buckminster builds running on
Jenkins. These builds are on the same server as SVN but still connect using
svn+ssh and the error occurs more reproducibly there.

P.S.
We have faced the same problem with svn+ssh protocol in the local network too. When using svn+ssh over Internet the problem is fading away.

0000406: infinite loop in HTTPConnection.request() with invalid server cert

Thu, 10 Mar 2011 20:20:27 +0300

similar situation as in http://svnkit.com/tracker/view.php?id=301 [^]

since recently we use the svnkit library together with svnclientadapter in the netbeans subversion plugin.
While trying to access a repository via https we have run into the following scenario:
- a server returns a wrong certificate (mismatched host name)
- unfortunately, for whatever reason, no callback is invoked from svnkit so that there is no chance to either reject or a accept the cert
- the execution hangs in an infinite loop in HTTPConnection.request().

Further debugging showed us that while trying to establish a connection a SSLHandshakeException ("Received fatal alert: handshake_failure") is catched in HTTPConnection.request() but the following continue restarts the surrounding while loop.

we are able to reproduce only on some os and jdk configurations - e.g. 1.7.0-ea; Java HotSpot(TM) Client VM 21.0-b02 on two different linux distributions or jdk 1.6_24 on solaris.

the commandline client works fine even with the wrong cert when accepted

obviously, the setup is a bit pathological, yet there stil is no excuse for the svnkit to hang infinitely because of a wrong configuration.

let us know if there is some more information we could provide...

thanks

0000407: Possibility to manage socket's options

Thu, 10 Mar 2011 20:20:05 +0300

We are using the SvnKit library in our application.
Some times on some machines we have the following problem:

java.net.SocketException: Connection reset by peer: socket write error
at java.net.SocketOutputStream.socketWrite0(Native Method)
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)
at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)
at java.io.BufferedOutputStream.write(BufferedOutputStream.java:109)
at java.io.FilterOutputStream.write(FilterOutputStream.java:80)
at org.tmatesoft.svn.core.internal.io.svn.SVNWriter.write(SVNWriter.java:98)
at org.tmatesoft.svn.core.internal.io.svn.SVNConnection.write(SVNConnection.java:318)
at org.tmatesoft.svn.core.internal.io.svn.SVNCommitEditor.addFile(SVNCommitEditor.java:138)
at org.radixware.kernel.common.svn.SVNEditor.appendFile(SVNEditor.java:69)
at org.radixware.manager.operations.LoadUpgradePacketOperation.process(LoadUpgradePacketOperation.java:141)
at org.radixware.manager.operations.BaseOperation.execute(BaseOperation.java:146)
at org.radixware.manager.operations.BaseOperation.run(BaseOperation.java:106)

After some experiments I managed to reproduce the problem repeatedly by commiting 500 MB.
Server: P4, Windows Server 2003, svnserve.exe as service, without firewall, antivirus, etc.
Client: Core I7, Windows Server 2003, svnkit, without firewall, antivirus, etc.

I found the following:
1) Commit is processed successfully by means of svn.exe or tortoise on the very client PC!
2) Commit is processed successfully via svnkit from other PCs.
3) The problem still appears if the server and the client are connected directly by a cable (without swiches).
4) The connection reset may occur not only in SVNCommitEditor.appendFile, but in 'applyTextDelta', 'sendDelta' at a random moment.
5) After disabling 'Large Send Offload' option of the client's network adapter the problem disappeared.

But it's inconvenient for us to ask all our clients to disable the 'Large Send Offload' option.
Especially taking into account that svn.exe works correctly.

I also found another solution.
Setting socket buffers size to 512 bytes solves the problem.
I did the following:
SVNRepositoryFactoryImpl.setup(new MySvnConnection());
Where:
MySvnConnection is a copy of ISVNConnectorFactory.DEFAULT that creates MySvnPlainConnector.
MySvnPlainConnector is a copy of SVNPlainConnector executing the folowing code after a socket creation:
mySocket.setSendBufferSize(512);
mySocket.setReceiveBufferSize(512);

This is a temporary solution.
I'm going to replace it by a reflection hack to decline code coping and to keep SSH and tunnels working.

I was wondering if it is possible to create some API for managing socket's options in the SvnKit library.
It will allow to create a better solution.

0000405: memory on checkout large repository

Thu, 10 Mar 2011 20:19:18 +0300

Checking out a large repository leads to an OutOfMemoryError exception.

FATAL: Java heap space
java.lang.OutOfMemoryError: Java heap space

See the attached file for a view of the memory dump. It seems that org.tmatesoft.svn.core.internal.wc.admin.SVNWCAccess keeps an entry for every single file in the repository. This naturally leads to an out of memory condition given enough files.

0000401: Reexport of jar archive not working in Eclipse Plugin Development

Tue, 15 Feb 2011 19:11:57 +0300

Eclipse Version: 3.6.1
SVNKit 1.3.5

I want to use SVNKit-Lybrary in an eclipse plugin project.

First of all i do the following step:
1. Create Plugin project
2. Add org.tmatesoft.svnkit_1.3.5.7406.jar as plugin dependency.
3. Import import org.tmatesoft.svn.core.wc.SVNClientManager;

-> The type SVNClientManager is not recognised in the plugin project.

If I move the class files from svnkit.jar (which is inside org.tmatesoft.svnkit_1.3.5.7406.jar) directly into org.tmatesoft.svnkit_1.3.5.7406.jar the type SVNClientManager is recognised.

The manifest.inf files looks ok, i guess reexport from jars inside a plugin is not supported (anymore).

Also found a mailing list entry:
http://osdir.com/ml/version-control.subversion.javasvn.user/2008-01/msg00043.html [^]

0000400: Wrong SSH host key fingerprint displayed

Tue, 15 Feb 2011 19:11:57 +0300

When I try to check out a repository via svn+ssh with any host, I am prompted to confirm the host key fingerprint. This fingerprint is invariably incorrect.

For example, try to check out this (nonexistent) repository:

svn+ssh://login.ccs.neu.edu/foo/ [^]

I am prompted with the RSA fingerprint 37:bd:4e:7f:7f:7f:49:48:cd:7d:e3:58:ab:6c:04:ef:46:2c:4d:82. However, that server's RSA fingerprint is d0:5b:da:56:c9:2b:03:b8:33:3c:d9:1b:24:fc:20:64.

This mismatch occurs for *every* computer I try to connect to, with a different (yet consistent) incorrect fingerprint each time.

0000399: jna.dll and jna.tmp files left in user's temp directory

Tue, 15 Feb 2011 19:11:57 +0300

Issue is still present within the 1.3.5 version.

P.S.
From original report (https://bugs.eclipse.org/bugs/show_bug.cgi?id=333194 [^]):

We have an RCP application built on top of Eclipse 3.4.2.
Install the Subversive plugins via archived updatesite
Subversive-incubation-0.7.9.I20101001-1700.zip
Additionally install SVN connectors from the following updatesite
http://community.polarion.com/projects/subversive/download/eclipse/2.0/update-site/ [^]

Now launch the RCP application and go the SVN Repository Exploring perspective.
Open user's temp directory in Windows Explorer - User\Local Settings\temp on
Windows XP.
jna*.dll and jna*.tmp files get created.
Close the RCP application and launch again. Go To SVN Repository Exploring
perspective.
Bug - additional jna*.dll and jna*.tmp files have been created in the temp
folder.

Reproducible: Always

0000398: When SASL allows ANONYMOUS authentication jsvn still asks for user/password

Tue, 15 Feb 2011 19:09:58 +0300

With a configuration similar to the one used in issue 384 (http://svnkit.com/tracker/view.php?id=384 [^]) comment 0000883, but modified to allow ANONYMOUS authentication, the user and password are still requested.

A proposed fix is attached.

Here's the modified configuration:

svnserve.conf:

[general]
anon-access = none
auth-access = write
# password-db = passwd
# authz-db = authz
realm = foo

[sasl]
use-sasl = true
# min-encryption = 0
# max-encryption = 256

/etc/sasl2/svn.conf:

pwcheck_method:saslauthd
mech_list: ANONYMOUS PLAIN

0000403: SVNKit should have option to disable gzip encoding for HTTP(S) connections

Tue, 15 Feb 2011 19:09:33 +0300

I was attempting to use SVNKit on Android. But was getting a "crc mismatch" when it would connect to an http svn repository.

Turns out this is an issue with the version of Apache Harmony used on Android 2.2 (not sure how far back it goes in Android). The version of GzipOutputStream has a bug when used with a network stream.

I would like to request an option to disable gzip encoding. A system property would work nicely. Just a property that could be set at the beginning of the main function or whatever.

0000397: While deleting the revision i am getting this error...

Tue, 15 Feb 2011 19:09:01 +0300

Hi,
I have one situation to delete particular revision from SVN repository. So, am getting this error.

org.tmatesoft.svn.core.SVNException: svn: Item '/cixAdmin/docColl/344/Enhancements List.ods' is out of date
svn: DELETE of '/svn-repos/cixAdmin/!svn/wrk/2d60616f-2d01-0010-9029-cb9e00ce62c0/cixAdmin/docColl/344/Enhancements%20List.ods': 409 Conflict (http://efycaci.stg.com [^])

and

org.tmatesoft.svn.core.SVNException: svn: File or directory '/cixAdmin/docColl/344/Enhancements%20List.ods' is out of date; try updating
svn: The version resource does not correspond to the resource within the transaction. Either the requested version resource is out of date (needs to be updated), or the requested version resource is newer than the transaction root (restart the commit).
svn: CHECKOUT of '/svn-repos/cixAdmin/!svn/ver/13050/cixAdmin/docColl/344/Enhancements%20List.ods': 409 Conflict (http://efycaci.stg.com [^])

I have pasted my code in this cyclic mail(at top). Is it possible to delete revision from repository?

0000395: How to Delete particular revision of file from SVN Repository using java code

Tue, 15 Feb 2011 19:08:17 +0300

Hi,
I have tried to delete particular revision from svn-repository. But, i can delete only file. I want to delete particular revision. I dont know how to delete and give path of particular revision.

This is the code

public void deleteDocRevision(String collDir, String fileName, Long revNum)
throws SVNException {
if (logger.isDebugEnabled()) {
logger.debug("deleteDocRevision(String, String, Long) - start"); //$NON-NLS-1$
}

String path = this.getPath() + "/" + DOC_COLL_FOLDER_NAME;
path = path + "/" + collDir;
String filePath = path + "/" + fileName;

SVNNodeKind kind = this.getTheRepository().checkPath(filePath, revNum);

if (kind == SVNNodeKind.NONE) {
SVNErrorMessage message = SVNErrorMessage.create(
SVNErrorCode.BAD_FILENAME, filePath + " Not found");
throw new SVNException(message);
}

try {

ISVNEditor editor = this.getTheRepository().getCommitEditor(
"file deleted", null);
editor.openRoot(-1);
editor.deleteEntry(filePath, revNum);
editor.closeDir();
editor.closeEdit();
} catch (Exception e) {

logger.error("deleteDocRevision(String, String, Long)", e); //$NON-NLS-1$
e.printStackTrace();
}

if (logger.isDebugEnabled()) {
logger.debug("deleteDocRevision(String, String, Long) - end"); //$NON-NLS-1$
}
}

0000301: SSL handshaking failure in HTTPConnection results in infinite loop

Tue, 25 Jan 2011 16:50:04 +0300

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.

0000394: Invalid implementation of the class 'SVNClientImpl$getVersion'

Fri, 07 Jan 2011 21:50:55 +0300

The method 'getVersion' of the class 'org.tmatesoft.svn.core.javahl.SVNClientImpl' is wrong. The returned 'Version' instance provides the client version rather than the underlying "native" library.
Therefore it provides a version number "1.3" rather than the Subversion version "1.6" .

MantisBT - Issues

0000415: SVNRepository.log(..) - SVNLogEntryPath objects should indicate property changes

0000311: Actions hang 1024 seconds before they complete

0000414: OverlappingFileLockException in SQLJet

0000412: FSRepositoryUtil.copy is static and synchronized

0000413: The open connection code uses a global lock for connecting to any server and not a lock per server

0000411: SVNSocketFactory: ISVNCanceller is never null

0000391: please deploy svnkit-cli project to Maven repo

0000402: svn: Handshake failed, received : '...' or '( success ( 2 2 ( ) ( edit...'

0000410: the path returned from the SVNPathUtil.append(String,String) does not have the same semantics as arguments

0000409: Server advertising SPNEGO auth results in SVNKit dying with SecurityException

0000408: doLock fails silently when a lock could not be taken

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

0000404: Exception due to race condition when using svn+ssh

0000406: infinite loop in HTTPConnection.request() with invalid server cert

0000407: Possibility to manage socket's options

0000405: memory on checkout large repository

0000401: Reexport of jar archive not working in Eclipse Plugin Development

0000400: Wrong SSH host key fingerprint displayed

0000399: jna*.dll and jna*.tmp files left in user's temp directory

0000398: When SASL allows ANONYMOUS authentication jsvn still asks for user/password

0000403: SVNKit should have option to disable gzip encoding for HTTP(S) connections

0000397: While deleting the revision i am getting this error...

0000395: How to Delete particular revision of file from SVN Repository using java code

0000301: SSL handshaking failure in HTTPConnection results in infinite loop

0000394: Invalid implementation of the class 'SVNClientImpl$getVersion'

0000399: jna.dll and jna.tmp files left in user's temp directory