Questions and Answers

The "problem" is ssh itself. Subversion creates for each command sending a tunnel to the repository. And on each tunnel it is a new ssh connection. And for every connection ssh must authenticate. This may you fix when you store your local public identity to the host containing the repository. If your public identity has a password, ssh-agent will asked (when ssh-agent is installed).

When you're running a ssh-agent before starting kdesvn, you should add your identity to its cache, kdesvn will not modifiy it due security reasons, so it would ask for your password again and again. (see Manpage of ssh-add)

It may not switched off. This is a feature of ssh-agent itself, when it see it has a terminal it asks for password in terminal not in a X-Dialog like kdesvnaskpass. (see Manpage of ssh-add).

Updates may only displayed when the remote server is subversion 1.2, too. Eg., seems that repository runs with subversion <1.2. It is not planned that kdesvn do that check recursive itself - this makes no sense. Ask for upgrading repository to newer subversion.

There are many reasons why the program couldn't load. This mostly happens when you building subversion-libs yourself. In that case you may check out issue entry.

The next big thing could that you forgot to give a libsuffix on 64-Bit systems at compile-time. So the part will installed in $PREFIX/lib instead of $PREFIX/lib64. So give -DLIB_SUFFIX=64 as paramter to cmake.

If this does not solve your problem, you may try out on a console:

  export LD_PRELOAD=/usr/lib/kde3/libkdesvnpart.so
  kdesvn
  unset LD_PRELOAD

You should see a lot of output why loading of libkdesvnpart.so isn't possible, that may help solving your problem.