[KDev4] VCS Integration

[Kris Wong]

> Uhm, I was talking about svnqt library, not the kde ioslaves. And
> looking at the kdesvn app I'd say it can do pretty much anything svn
has
> to offer so I don't see why the library it uses would not provide all
> functionality we need.

Given that this is the library used by kdesvn the question becomes, how
well maintained is kdesvn, and how well maintained is it likely to be
going forward?

> Well, as always its "who codes decides" and if dukju is familiar with
> the svn API already its pretty pointless to discuss this as in that
case
> he would need to spend more time to learn the svnqt API.

He may have to spend more time to learn svnqt, but given that he is
already familiar with both, combining them isn't exactly a stretch.  I
wouldn't dismiss the idea if it is the right decision for the project.

> Well, we'd do that even when using svnqt, as it does use svn libs
under
> the hood too. It only provides a 'qt-ized' object oriented layer on
top
> of them. Which is exactly the reason I find that API easier to
> use/understand than the C-API from svnlib. For example there's a class
> for the Working Copy, for executing svn actions via a Client class and
> quite some more.

I have written an svn interface using the client libraries (C API), and
I can tell you there is a learning curve associated with it.  I assume
it would be much easier for other kdevelop developers to make
modifications if the integration were written using the svnqt library (I
have not actually looked at the library, but given Andreas's comments).

> There's one additional thing: svnqt is using Qt3 at the moment, so it
> needs to be ported. However I don't expect that to me much of a
problem,
> QString hasn't changed that drastically and neither did QByteArray and
I
> think thats pretty much all the classes that the svnqt lib uses.

Since kdesvn is using this library, it will need to be ported anyway.

Using the client libraries gives kdevelop greater flexibility with less
maintainability.  Using svnqt gives kdevelop (possibly) less flexibility
with greater maintainability.  I would base the decision on how likely
the svnqt library is to be kept up to date going forward.

Kris Wong