[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Cervisia development
From:       Richard Moore <rich () ipso-facto ! freeserve ! co ! uk>
Date:       2001-09-12 20:58:54
[Download RAW message or body]



Ralf Nolden wrote:
> 
> On Dienstag, 11. September 2001 23:42, Bernd Gehrmann wrote:
> 
> As a sidenote, we received a message on kdevelop-devel about comitting to a
> CVS repository over SSH, so there's two things which need to be checked IMHO:
> a) can cervisia handle ssh logins with password requests ?
> b) is there a chance that password logins can be added that way so we can
> make use of the cervisia part in kdevelop as a frontend ? I know Matthieu is
> working out some things on having a general VC frontend to various CVS
> backends (even those that we can't afford having a license for but companies
> do and use these), so I think we should all incorporate these things in a
> cervisia over time that supports more than CVS. Is that possible Bernd ? How
> is the status on the part specifically to be used in KDevelop 3 ?

Adding support for other VC systems should be pretty easy with the
re-factored version of the code I'm working on. In particular I've
tried to ensure that RCS and Subversion support should be possible.

Rich.

> 
> Ralf
> 
> > On Tue, 11 Sep 2001, Richard Moore wrote:
> > > I've been thinking about how we should deal with the Cervisia
> > > development issues (mainly how to maintain a stable 2.x codebase).
> > > You've already said that you want to keep the sourceforge CVS
> > > running on KDE 2.x, so how about we make the kdesdk version the
> > > 'development tree' which would aim to work with 2.x, but would
> > > have the KDE 3.x HEAD as the primary target. We should be able
> > > to sync compatible patches between the two trees without too much
> > > problem, I guess. Whenever I'm happy with a feature, and have a
> > > tested 2.x patch I'll mail it to you for inclusion in the
> > > sourceforge tree. What do you think, is this ok?
> >
> > Well, if you can make the version in kdesdk work with both KDE versions,
> > I don't think it's necessary to maintain a separate one else-
> > where. Maybe that becomes more convenient when the differences are
> > more than a couple of small #ifdef's, but I think we'll see early
> > enough whether that's the case.
> >
> > Currently, I have a local copy that is approximately the stuff
> > after your KAction changes, but before the use of KParts, plus
> > some bugfixes. I hope to implement some micro-features in this
> > source tree next weekend (and merge them into the KDE repository)
> > and release all that as 1.5 afterwards. I think that's
> > a good intermediate step instead of publishing the bugfixes that
> > have accumulated during the last months and your more 'radical'
> > changes together.
> >
> > > Currently my local copy has diverged quite a bit from both CVS
> > > versions, as I've been separating the front and back ends of the
> > > app. This change has let me write a Cervisia plugin for other
> > > apps. The plugin can extend arbitrary KParts (eg. Kate and KHTML
> > > (and hopefully the KOffice apps too)) by adding a 'Version
> > > Control' sub-menu to their file menus. The menu operates directly
> > > on the file open in the part, but there is a bit more work still
> > > needed to make everything integrate nicely (eg. the part should
> > > be reloaded after a cvs update). Adding a DCOP interface to allow
> > > scripting is trivial now I have a standalone API for invoking the
> > > Cervisia actions, and should be working RSN.
> >
> > Great :-)
> >
> > Bernd.
> 
> --
> We're not a company, we just produce better code at less costs.
> --------------------------------------------------------------------
> Ralf Nolden
> nolden@kde.org
> 
> The K Desktop Environment       The KDevelop Project
> http://www.kde.org              http://www.kdevelop.org

[prev in list] [next in list] [prev in thread] [next in thread]