RFC for Version Control Plugins handling ...

[Mario Scalas]

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

Hi 

> I don't agree. Version systems really have 2 sides (from kdevelop point of
> view) : one outside the project (creation), and one inside
> (commit/update/what_ya_want) In addition, splitting in 2 parts makes some
> things easier. For example I want to be able to create a CVS-based project,
> but when I'm working on a Subversion-based one, I really don't want to have
> the CVS stuff in context menu... Of course this problem can be solved
> another way, but it seems more natural to me to have 2 plugins, and in fact
> I don't see a reason why it would be better to have only one. I'm not sure
> the Scope notion is a good thing in general, but this is another problem
> :-)

So finally I got the idea that was behind the globalcvs existence :) Still 
seems to me an overkill :/
What I imagine is a set of vcs plugins visible from the IDE itself (so from 
Settings->Configure gideon->Plugins and _not_ from 
Project->Options->Plugins): the user will enable what best fits his needs 
(Cvs, perforce, clearcase, ...) having the "customized" context menu as 
consequence of his choice.
To know about the installed vcs, we could do a KTrader query in the 
Application Wizard for every plugin which is a vcs using, for example, 
"ServiceTypes=KDevelop/VCS" in the associated .desktop files. The application 
wizard will "temporary" activate all of the found plugins (it doesnt't seem 
an heavy toll) so every vcs could show its configuration dialog: once the 
preferred vcs has been chosen, the others will be unloaded. 
To avoid the KTrader we could simply assume that the AppWizard we'll permit 
the use of only the vcs currently loaded (so if I checked "perforce" and 
"cvs" he will let me choice between "none", "cvs", "perforce").
I personally back the idea that it is simpler to have n plugins than 2*n 
("global" only for creation/import, "worker" for IDE integration) to 
maintain/develop/handle 8-/ 

> > - - (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.
>
> If I'm right, the KDevVersionControl is not used at all, except in
> interfaces ;-)

Yes, seems that the implementation started on two parallel still distinct ways 
... Ok, seems I was right this time (no ultra-cunning design here ;)

> > 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
>
> Strongly agree!

It seems that the KParts::Plugin is also an over-necessary level in the class 
hierarchy of KDevPlugin (roberto is much more experienced than me so I asked 
about it to him on #kdevelop: he sees no advantage in using KParts::Plugin 
since gideon uses its own plugin loading scheme) 

> > 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
>
> You've got one of the two :-)

Nice :) (Well, really I got mail from harryF too and hope he will partecipate 
to this discussion soon since he has plans about it too but was too busy this 
week-end :)

> Bye,
> Yanngg

Bye
Mario

Ps: sorry for the too many "seems" ... should search a synonim for this word 
;)

> _______________________________________________
> Kdevelop-devel mailing list
> Kdevelop-devel at barney.cs.uni-potsdam.de
> http://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel

- -- 
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+tYsWkfH25fNf4bcRAjoWAJ9uJnMWvjQyvtqPXSK/7eO884elpwCeITv6
L8enzZ8E8re36y2v2/uHnLg=
=PGLR
-----END PGP SIGNATURE-----