RFC for Version Control Plugins handling ...

Mario Scalas mario.scalas at libero.it
Sat May 3 17:05:09 UTC 2003


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all,
	as I told to roberto in #kdevelop, I think to have figured out the meaning of 
parts/cvs/globalcvs: it only serves to fill the combobox when choosing the 
particular version control in the application wizard. But:
- - kdevglobalcvs.desktop has the following entry:
   X-KDevelop-Scope=Global
- - all other vcs plugins .desktop files have instead:
   X-KDevelop-Scope=Project

This means that the application wizard (_as it is coded_ in 
AppWizardDialog::AppWizardDialog(AppWizardPart *part, QWidget *parent, const 
char *name):173) will alway display "CVS" as vcs system (if gideon is 
configured to load the globalcvs plugin, that is: if the option is unchecked 
no vcs will be shown). I don't know anything of perforce or clearcase but no 
user will never be able to use them in the application wizard!

In addition:
- - there is redundancy between KDevGlobalVersionControl and KDevVersionControl: 
only one should exist and the existent functionalities should be merged (this 
is the current status of the cvspart classes, for example: 
http://www.gicomsrl.it/mario/cvspart_classes.png).

What I propose is:
- - merging parts/cvs/globalcvs and parts/cvs functionality wise (globalcvs 
seems not complete anyway), ultimately removing parts/cvs/globacvs from 
codebase.
- - if plugin scope's concept must be retained then parts/clearcase, parts/cvs 
and parts/perforce must have "X-KDevelop-Scope=Global" so that they can be 
used from the wizard all at once. Having them on "Project" scope makes them 
not usable or simply require over-complex coding (anyway the user should be 
able to unload the vcs he doesnt use from Settings->Plugins dialog).
- - (about KDevGlobalVersionControl Vs KDevVersionControl) the latter should be 
retained since (1) it used in more header and so modifications should impact 
on less modules and (2) the name is just-what-it-means. The killed one should 
be merged in KDevVersionControl.

Future improvements:
- - vcs should have actions associated, so that they can be embedded in the user 
interface (menu, toolbar?)
- - I'd like to further investigate if KParts::Plugin is useful for our needs. 
Any idea about this?
- - all vcs should heir from KDevVersionControl instead of KDevPlugin directly 
(well, and KDevPlugin from KParts::Plugin then ;)
- - everything can be useful and doable:)


Please provide feedback about these (well, personally i'd like to know from 
hodique or harald about the globalcvs and if I'm right about it ;).

Ciao
Mario (aka marioS ;).

Ps: sorry for any spelling error ;)

- -- 
Mario Scalas <mario dot scalas at libero dot it>
Miser miser! Modo niger et ustus fortiter.
homepage: http://digilander.iol.it/zakuteam
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+s/ZVkfH25fNf4bcRAv6EAKCLEAIVZkHRBMZQV8LN1WHoyfkBLgCeOvGY
y7kQPwd3EIXb8ZxRCkk9DHo=
=JL1Z
-----END PGP SIGNATURE-----





More information about the KDevelop-devel mailing list