Future development of kdesvn

Share on FacebookTweet about this on TwitterShare on Google+

It’s time thinking about how the development should be done in future or what should be done.
As you know, kdesvn is splitted into three parts:

  1. The standalone application with full featured subversion UI
  2. A KIO interface let you browse in subversion repositories from within filemanagers (ksvn+xxxx)
  3. A commandline interface which is very basic including menu entries for filemanagers

Current state

The UI this moment is more/less just a graphical interface to the most common subversion commands. It has no real defined workflows integrated (branching, tagging etc.), user has to know what them have to use. But it interact with other KDE components for instance export/import with drag&drop from dolphin or other filemanager.

KIO is very basic, it is a simple chance displaying contents of SVN repositories including views on specific revisions from within standard filemanager. With the commandline interface of kdesvn some context menus are integrated which let you do some basic stuff.


Following wishes I’d got last years:

  1. Let the UI more workflow specific, eg, “Branch” and “Tag” instead of “Copy”, better bugracker integration
  2. Let have filemanager context menus more options to do like TortoiseSVN or RabbitCVS so starting the UI isn’t necessary
  3. When open a working copy in standard filemanager display overlay icons showing the state of items in working copy, eg, better transparent integration into standard KDE components


  • First of all: Time. I’m not able any more, writing the code AND writing documentation and translations. This is one of the reasons for the move to KDE’s git.
    But this problem means: I’m not able and not willing make bigger enhancements to UI AND to commandline/KIO at the same time.
  • The subversion C-Api: Meanwhile I hate every new release of subversion ’cause in every release them change their API and flooding my code with deprecated messages or force me changing my OWN internal API due incompatible changes (like relative vs absolute pathes of items). It needs meanwhile more time than integrating new features.
    So I’m searching for ideas how to handle this a better way.
  • I have no idea how to integrate kdesvn deeper into dolphin and co (like overlay icons on working copies, handle filemanager copies/moves and so on).
    May I just didn’t found the documentation of it.

Resulting Questions

  • What would you say kdesvn development should prefer? UI or KIO/commandline?
  • Is there a possibility for deeper transparent integration into filemanagers? Is this wanted and/or needed?
  • Has someone an idea how to handle the permanent API changes of subversion liberaries?
  • What kind of subversion workflows from your point of view are needed inside UI?

It would be realy nice getting some constructive suggestions here.

13 thoughts on “Future development of kdesvn

  1. Henning Schnoor

    Hi there,

    first of all, thanks for developing kdesvn, it’s a very nice tool that I use often!

    Since you asked for feedback on what people use: Personally, I almost exclusively use the UI, since there I can get these nice views of the history of an item, including the very useful diffs.

    So, thanks again!

    – Henning

  2. Vasek

    First of all, many thanks for working on kdesvn, I use it regularly and it is a great tool.

    As for my greatest wish, I vote for deeper integration into the filemanagers. The more general, the better – I do not use dolphin. The overlay icons are the most useful advantage over the command line.

  3. Djuro Drljaca


    I would also like to thank you for the work you (and the rest of the developers) do on kdesvn.

    I personally would like to see kdesvn to be a similar to TortoiseSVN on Windows at least feature-wise … it is really convenient way of working with subversion 🙂

    For the subversion C-API I would suggest that you create a wrapper Qt library (if you haven’t done this already and just modify the internals of that library/class. Maybe there is already some Qt or at least C++ bindings available?

    1. Rajko Albrecht Post author

      As far as I know I wrote the only qt binding to subversion which based on the c++ binding of RapidSVN. Other C++ bindings aren’t known to me and I fear them would be useless to me even I want to use QT.

  4. SamTheHumle

    Hi alwin,
    not really a suggestion but just an incredible thanks for developing kdesvn. It’s an excellent tool that serves my purposes close to 100%, thus I use often!

    Keep up the good work


  5. Pingback: Links 21/8/2013: Diversity on the Desktop, Android as Distro | Techrights

  6. Keith Zubot-Gephart

    Personally I love the GUI client, although for a while I hadn’t gotten around to installing it on my work computer again because of the conflict with the kdesdk KIO plugins for SVN, which I do use daily with Dolphin. So my vote would be for the UI (which to this day is still the best I’ve used, for my own purposes at least; maybe I’m just too deeply entrenched in KDE!).

    As a sidenote, when I transitioned my work over from CVS to SVN (I’m essentially the entire IT department of a small, unfortunately-Windows-centric software development company, but as the backend guy I get away with using Linux as my desktop OS) I found kdesvn incredibly helpful, especially as someone who had touched the commandline client once or twice but was otherwise still figuring it out, and tinkering with test migrations of our CVS repo.

    At this point, half a year later, I’m comfortable enough with the pure standard svn commandline that I’m not in as dire need of a GUI, although this post reminded me, and I’ve now reinstalled it with a bit of dpkg –force (I’m on Kubuntu) to exclude the specific KIO dependency. But being able to play around and edit things using kdesvn probably saved me literally days of stumbling as I started the process of transitioning my work to Subversion, so many, many thanks. And thanks in advance for all the tiny things I’ll tinker with and fix for my company’s developers in an easier fashion using kdesvn now that I’ve got it reinstalled!

  7. Christian Loose

    In my opinion the most important thing is cooperation with KDevelop and their subversion plugin. It reduces duplication an is probably the only way to increase the number of people working on this code.

    1. Rajko Albrecht Post author

      On paper this sounds good, but the design differences are essential ’cause the goals are different, too and kdesvn does a lot more than kdevelops own subversion code.

      Switching to the svn-wrapper-library of kdevelop would mean, that I had rewrite a lot of stuff inside this wrapper which is already part of current svnqt library. Otherwise kdesvn will not work.

      This makes no sense.

  8. airdrik

    My vote goes to the KIO/dolphin integration, since it is a lot more convenient for me to browse around using dolphin than in the kdesvn UI itself; though if the UI provided more workflow/task oriented features I might start using it more (though most of our tagging and release branching is done via a dedicated version manager, and we don’t do much branching otherwise).

    My typical usage mostly revolves around update, commit, conflict resolution, and occasional checkout. I appreciate that most of this can be covered from dolphin. It would be nice to add resolve conflicts and conflicts resolved to the file manager context menu, and probably more importantly I would really like something to handle tree conflicts.

  9. MasterPrenium

    In my opinion the best would be the integration with file manager, just because there are lot of svn UI, maybe kdesvn is better but alternative exists !
    While if we could have a really great integration with file manager, like having a repository in a folder that will work completly transparently like if it was not on a repo that would be great (basic fonctions will act like on “standard” files. ie : rename will rename via svn, delete etc …), a way to know easily (icons / color) if a file is added or not to the svn, a way to know if the repos is up to date ect … That would be really great I think.

  10. Timothy C. Quinn

    I would love to see an option to load to a subfolder in a SVN repo but still have the tree section show the entire repository folder structure with appropriate folders opened. Having kdesvn open with just the child folder makes it such that I have to close the tool all the time to see parent folders. This does not help me much and there is no way to go up a parent.

    Thanks for all your help in building this tool!


Leave a Reply

Your email address will not be published. Required fields are marked *