KDE/kdevelop/lib/plugins/vcs/interfaces

Andreas Pakulat apaku at gmx.de
Thu May 31 21:26:43 UTC 2007


On 31.05.07 15:20:42, Matt Rogers wrote:
> On Thursday 31 May 2007 14:58, Andreas Pakulat wrote:
> > On 31.05.07 14:32:16, Matt Rogers wrote:
> > > On Tuesday 29 May 2007 11:32, Matthew Woehlke wrote:
> > > > (I tried to reply to your commit log but don't see the message yet...
> > > > might be moderated or blocked because I sent from a different address.
> > > > So apologies if it shows up later and duplicates this :-).)
> > > >
> > > > Andreas Pakulat wrote:
> > > > > On 27.05.07 21:04:33, Matt Rogers wrote:
> > > > >> On Sunday 27 May 2007 20:53, Andreas Pakulat wrote:
> > > > >>> SVN commit 668891 by apaku:
> > > > >>>
> > > > >>> add exec() which runs the job in a synchronous way
> > > > >>
> > > > >> Why? Under what circumstances would we need the synchronous way of
> > > > >> doing things?
> > > > >
> > > > > For simple scripts for example, those don't have signal/slot stuff
> > > > > set up necessarily.
> > > >
> > > > Right. Btw, whatever happened to wait()? Should we have exec(), wait()
> > > > or both? (Note: exec() == start()+wait() if we have wait().)
> > > >
> > > > To answer Matt: scripts generally run sequentially, it is I think much
> > > > easier to write a script that way than to all the time tie the
> > > > finished() signal to starting the next step of the script.
> > >
> > > How bout for right now we don't care about scripts and instead focus on
> > > actually making a usable IDE? If somebody is using the IDE, why would
> > > they write scripts?
> >
> > Because they want to automate tasks, also look at the recent wishlist
> > report about "open foo.cpp" and have it show up in KDevelop.
> 
> My objection is that we have no one using this functionality already and it 
> overlaps with already existing functionality (aka command line clients). It 
> seems like we're just adding it because we think it would be cool. If people 
> want to write scripts to interact with version control systems, they should 
> use the command line version of said version control system. The only version 
> control system that doesn't have an command line version is Visual SourceSafe 
> and I don't want to support that from within KDevelop anyways.

So we should just drop what we have and revert to the interface we have
implemented already? 

Also quite some of the functionality may be used by other plugins, think
about getting a diff to head and sending that through teamwork to
somebody who doesn't have access to the vcs (for whatever reason). Its
not simply about scripts, its about exposing part of the functionality
of the VCS in a way that is usable by other code and not just displayed
to the user.

Andreas, who will continue to work on new interfaces and help the VCS
authors to implement them

-- 
Do not overtax your powers.




More information about the KDevelop-devel mailing list