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

List:       kde-core-devel
Subject:    Re: Cervisia development
From:       Ralf Nolden <nolden () kde ! org>
Date:       2001-09-12 6:52:54
[Download RAW message or body]

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 ?

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]