This same issue persists in 1.7.4. After cursory analysis my belief is that if any subclass of SVNBasicClient is used that creates a repository pool, there is no sensible way to dispose of this pool (the pool is an implementation detail of the client, but the client classes never seem to dispose of it). Without disposal, the static timer in SVNRepositoryPool holds instances forever. The simple fix would be to add dispose methods to these clients, but of course then every user needs to know to call these methods. That is just spreading a design choice (requiring explicit disposal) which is asking for leaks.

This seems to be a critical issue

Hello. Thanks for the report and the analysis. You're right, the repository pool could not be disposed. I've fixed the problem in trunk.
If you have a possibility and the problem is reproducible for you, please have a try.

The recommended way to create a client is to use SVNClientManager (an example for SVNCommitClient)

        SVNClientManager clientManager = SVNClientManager.newInstance();
        try {
            SVNCommitClient commitClient = clientManager.getCommitClient();
            //work with commitClient
        } finally {
            clientManager.dispose();
        }

In this case SVNClientManager implements ISVNRepositoryPool and passes itself to every client it creates. So dispose() is called explicitly in this case.

With new API SvnOperationFactory disposes (in SvnOperationFactory#dispose) pools that it creates itself, but doesn't dispose pools that are passed to it. I've made SvnOperationFactory#setAutoDisposeRepositoryPool setter public in the latest trunk revision to let the user control repository pool disposal manually.

SVNXXXClient classes do not have dispose() method by design. Do not construct them directly, but use SVNClientManager as in the example above or (even better) new API based on SvnOperationsFactory.