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

List:       kde-core-devel
Subject:    Re: Cervisia development
From:       Bernd Gehrmann <bernd () physik ! hu-berlin ! de>
Date:       2001-09-11 21:42:12
[Download RAW message or body]

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.

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