[KDev4] VCS Integration

[Andreas Pakulat]

On 14.03.07 17:10:58, Matt Rogers wrote:
> On Mar 14, 2007, at 2:56 PM, Andreas Pakulat wrote:
> > On 14.03.07 15:29:23, Alexander Dymo wrote:
> >> Yes, high level library is good to have. But it's not really  
> >> necessary to have
> >> dependency. kdesvn has a library called svnqt which I guess is  
> >> their port
> >> of rapidsvn. We could have a copy of svnqt in our repository too.
> >
> > Did that work good in KDev3? If not why should it work better in KDev4
> > (I mean having a full copy of a library inside KDevelop source tree).
> > Also I don't think this is a very good idea, because I think we should
> > ship svn+cvs plugin as part of our platform (else quanta users may  
> > need
> > to install kdevelop just to get svn support). And a full svn-qt lib in
> > our platform is not a good idea.
> >
> >> If we will not have a copy of svnqt, we will most likely write our  
> >> own qt/c++
> >> wrapper around svn anyway.
> >
> > As I said in another thread already: Why do we need to re-invent the
> > wheel? We're short on manpower already, so we should try to re-use
> > existing libraries and code.
> 
> It's not reinventing the wheel because what's currently there doesn't
> provide the functionality we need and changing what's there to
> provide the functionality we need would be mean more time and effort
> than just starting over.

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. 

> Not to mention that we have a new person  
> doing this anyways, so we're really only adding to the available  
> manpower.

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.

> Let's also not forget that using svn's libraries is  probably the best
> technical solution for our needs.

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.

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.

Andreas

-- 
You will inherit some money or a small piece of land.