[KDev4] VCS Integration

[Andreas Pakulat]

On 15.03.07 08:33:38, Kris Wong wrote:
> > 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?

To me it seems that the maintainer is still interested, but lacks time.
I recently opened a bugreport about the missing import functionality in
kdesvn-ioslave and it took several days for him to come back to me.

The library is pretty much "on its own" in the kdesvn source, i.e. its
not a large problem to extract it (tried it, was a matter of minutes,
except that I needed some kde4-libs cmake stuff to "fix" the missing
cmake code for finding the library dir). So I think we should talk to
the maintainer how much time he has and wether he'd like to move the
library out of kdesvn and release it separately (because for kdevelop
its probably better to depend on a lib than on a whole application, even
though some distros package the library separately). If he doesn't have
enough time to keep up with subversion I'm all for doing it on our own
because then copying it into our source code would still mean we'd have
to do all the maintenance.

> > 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 looked at the api docs earlier today and the first problem I had was
that I didn't find a listing of functions, only modules and datatypes.
And the modules didn't contain anything that is related to the
client-part of the svn library AFAICS. I found the client functions then
when browsing through the list of header files, so thats the first
problem for new developers/people providing patches/...

> 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).

Well, comparing the client functions its pretty comparable, just that
svnqt wraps the import/checkout/... into a Client class, while with
svn-C you'd have to handle all the datastructures it needs. I'm
currently under the impression that there are only very few classes
needed to get going with svnqt, you need a Context and a Client and Path
to do a svn status, for an svn update you need Targets too (which is
basically a list of paths) and a revision. It would be cool if somebody
could look into svn-C api and tell what you need to setup for these two
actions there.

> > 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.

This part is nearly done, actually. The author uses CMake already and
allows to compile it with Qt4 by using some special defines for the
changes in QString and QList (QString::utf8 vs QString::toUtf8 and QValueList vs QList
basically). We may also need to check the source of QString::isNull()
uses, as TT discourages from using that and instead use isEmpty(), but
thats all that has to be done.

Andreas

-- 
Executive ability is prominent in your make-up.