VCS Integration

Hello!

As I've seen from the recent posts to the mailinglist, dukju
ahn is already 
working on bringing SVN support to KDevelop4, aren't you?

Is anybody working on the CVS integration? If not, I could
take that task.

However, to me, there are still some important questions to
solve?
Has there been any decicion on how to integrate version
controll systems?

Maybe like in KDevelop3 where each plugin has been able to
add items to a 
context menu? This method was very easy to use for the VCS
plugin, as it 
alredy got a list of files to work on from the Context
object.

I've also heard the idea of using an action-collection (or
so) where VCS 
plugins could register their actions? How could the transfer
of the needed 
filelist work here? 

On the WIKI I've found the idea of using an extension
interface? 
This sounds very interesting to me, as far as almoust all
version controll 
systems offer more or less the same functions. But still the
question of how 
to build the context menu and connect the actions to the
extension interface 
slots remains.


Greetings, Robert

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On 13.03.07 08:52:15, Robert Gruber wrote:
> Hello!
> 
> As I've seen from the recent posts to the mailinglist,
dukju ahn is already 
> working on bringing SVN support to KDevelop4, aren't
you?
> 
> Is anybody working on the CVS integration? If not, I
could take that task.
> 
> However, to me, there are still some important
questions to solve?
> Has there been any decicion on how to integrate version
controll systems?

No, I have a few things in my mind but nothing thought out
yet...

> Maybe like in KDevelop3 where each plugin has been able
to add items to a 
> context menu? This method was very easy to use for the
VCS plugin, as it 
> alredy got a list of files to work on from the Context
object.

Well, context menu will happen one way or another. More
important is
that we define a minimal extension interface that every VCS
can
implement. A quick thought brings up the following actions:

import (into repository)
chechkout
update
commit
diff
log

Then we need to have slots for file/dir renaming which we
can connect to
the project manager's signals.

> I've also heard the idea of using an action-collection
(or so) where VCS 
> plugins could register their actions? How could the
transfer of the needed 
> filelist work here? 

Well, actions should probably be available for the checkout
from
repository. Also I think some actions for viewing the
currently focussed
file's diff to repository and its log should exist.

Hope that helps for starters, as Alexander already said in
another
thread there's no decision been made about how context
menu's will work
in 4.0. I myself don't even know the pros/cons. I'll try to
discuss this
with Alexander on Wednesday evening on IRC to get an initial
proposal
for the list.

Andreas

-- 
Tuesday is the Wednesday of the rest of your life.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On Mar 13, 2007, at 3:34 AM, Andreas Pakulat wrote:

> On 13.03.07 08:52:15, Robert Gruber wrote:
>> Hello!
>>
>> As I've seen from the recent posts to the
mailinglist, dukju ahn  
>> is already
>> working on bringing SVN support to KDevelop4,
aren't you?
>>
>> Is anybody working on the CVS integration? If not,
I could take  
>> that task.
>>
>> However, to me, there are still some important
questions to solve?
>> Has there been any decicion on how to integrate
version controll  
>> systems?
>
> No, I have a few things in my mind but nothing thought
out yet...

Same here.

>
>> Maybe like in KDevelop3 where each plugin has been
able to add  
>> items to a
>> context menu? This method was very easy to use for
the VCS plugin,  
>> as it
>> alredy got a list of files to work on from the
Context object.
>
> Well, context menu will happen one way or another. More
important is
> that we define a minimal extension interface that every
VCS can
> implement. A quick thought brings up the following
actions:
>
> import (into repository)
> chechkout
> update
> commit
> diff
> log
>
> Then we need to have slots for file/dir renaming which
we can  
> connect to
> the project manager's signals.
>

We need more discussion about we actually want all the SCM
plugins to  
do.

>> I've also heard the idea of using an
action-collection (or so)  
>> where VCS
>> plugins could register their actions? How could the
transfer of  
>> the needed
>> filelist work here?
>
> Well, actions should probably be available for the
checkout from
> repository. Also I think some actions for viewing the
currently  
> focussed
> file's diff to repository and its log should exist.
>
> Hope that helps for starters, as Alexander already said
in another
> thread there's no decision been made about how context
menu's will  
> work
> in 4.0. I myself don't even know the pros/cons. I'll
try to discuss  
> this
> with Alexander on Wednesday evening on IRC to get an
initial proposal
> for the list.
>
> Andreas
>

How about we have that discussion on the mailing list
instead. I have  
chosen to no longer participate on IRC because I can never
get any  
other work done that way. Using email may be slower, but it
is wider  
reaching, and the archives are searchable, where as the IRC
logs are  
not.
--
Matt



_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On 13.03.07 12:01:24, Matt Rogers wrote:
> On Mar 13, 2007, at 3:34 AM, Andreas Pakulat wrote:
> > Well, actions should probably be available for the
checkout from
> > repository. Also I think some actions for viewing
the currently  
> > focussed
> > file's diff to repository and its log should
exist.
> >
> > Hope that helps for starters, as Alexander already
said in another
> > thread there's no decision been made about how
context menu's will  
> > work
> > in 4.0. I myself don't even know the pros/cons.
I'll try to discuss  
> > this
> > with Alexander on Wednesday evening on IRC to get
an initial proposal
> > for the list.
> 
> How about we have that discussion on the mailing list
instead. I have  
> chosen to no longer participate on IRC because I can
never get any  
> other work done that way. Using email may be slower,
but it is wider  
> reaching, and the archives are searchable, where as the
IRC logs are  
> not.

Fine with me and as I said thats what I wanted to do anyway.
I just
wanted to ask adymo what "other" idea he had for
context menu because
his last comment in another thread about this was really
short.

Andreas

-- 
Alimony and bribes will engage a large share of your
wealth.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On 13.03.07 12:58:55, Kuba Ober wrote:
> On Tuesday 13 March 2007, Andreas Pakulat wrote:
> > A quick thought brings up the following actions:
> >
> > import (into repository)
> > chechkout
> > update
> > commit
> > diff
> > log
> 
> What would all those do? What's an "import"?
Is this adding a file to a 
> change? Then checkout -- is it for whole tree, or for a
single file? What 
> does an update do?

import == bring a newly created project into a source code
repository
checkout == retrieve a project from a source code repository
and import
            it into kdevelop
update == sync your local copy with the source code
repository
commit == bring local changes into the source code
repository
diff == see the difference between your local copy and the
latest
        version in the repository
log == see a history of changes in the repository.

> Aegis, a nice software configuration systen, works on
whole trees, i.e. you 
> check out a read-only tree (a change), which has no
writable files, and only 
> symlinks, hardlinks/copies or even no links at all to
the read-only baseline. 
> 
> In the tree that you checked out you can copy
individual files to be 
> read-write, and work on them. Depending on the build
tool, you need symlinks, 
> hardlinks/copies, or you may live without links at
all.

Sorry, I don't follow you here. Could you give an example
session? Or
have a link to some introductory material?

I have to admit that I don't know all scm's out there, I
basically have
experience with those that use the checkout-work-checkin
cycle (namely
cvs, svn and a bit clearcase)

Andreas

-- 
You plan things that you do not even attempt because of your
extreme caution.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On Mar 13, 2007, at 11:57 AM, dukju ahn wrote:

> 2007/3/13, Robert Gruber <rgruberusers.sourceforge.net>:
>> As I've seen from the recent posts to the
mailinglist, dukju ahn  
>> is already
>> working on bringing SVN support to KDevelop4,
aren't you?
>
> Yes, I'm struggling on that 
>
>> Is anybody working on the CVS integration? If not,
I could take  
>> that task.
> No,  I don't know CVS exactly.
>
>> But still the question of how
>> to build the context menu and connect the actions
to the extension  
>> interface
>> slots remains.
>
> Plus, we need to decide how to show file's status, such
as
> modified, conflict, up-to-date, needs-update etc. I
think we can use
> existing file manager or project manager. VCS plugins
should provide
> interfaces for file status provider. Then filemanager
or project  
> manager
> can use these interfaces to display file status.
>
> I almost prepared the first draft of VCS interfaces.
That's a  
> slight addition
> and port from KDev3. I will commit it soon.
>
>

Please don't commit it. Submit it to the list for review
first.  
Incorporate the feedback received and then commit after
that.
--
Matt



_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

Hi!

> It's my general opinion that we need to avoid the use
of ioslaves for  
> SCM integration as much as possible. So the subversion
plugin should  
> use subversion's client API directly. As for CVS and
others, I'm not  
> entirely sure how that would work yet.

Unlike SVN, CVS does not provide any libraries. There is
just the commandline tool. 

So IMHO there are only two options. We either use the DBUS
interfaces from cervisia (just like we did in KDevelop3 with
dcop) and therefor depend on kdesdk or we have to run the
cvs command by ourself.

As far as cervisia already does the
cvs-commandline-tool-running thing, I think using their DBUS
interfaces definatly is the way to go.

Greets, Robert

-- 
"Feel free" - 5 GB Mailbox, 50 FreeSMS/Monat ...
Jetzt GMX ProMail testen:
www.gmx.net/de/go/mailfooter/promail-out

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On Wednesday 14 March 2007 05:43, dukju ahn wrote:
> In other thread of mailling-list, I read andreas'
article that KDev4
> will be directly linked to subversion library, not
using ioslaves.
> Then, what could be the candidate for such core
framework?

Linking directly sounds like a good choice now because we
had
too much problems with incompleteness of ioslaves and their
incompatibilities with each another.

kdesvn project is using RapidSVN's (http://rapidsvn.tigris.or
g/)
wrapper to the subversion C api. Maybe it's worth looking
at
as an alternative to svn api.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On Wednesday 14 March 2007 15:08, Andreas Pakulat wrote:
> Well, having had a short look at the C-API that
subversion provides I
> think it may be a good idea to use an API that is a bit
more high-level.
> And using the RapidSVN c++ lib means an external dep
too.

Yes, high level library is good to have. But it's not really
necessary to have
dependency. kdesvn has a library called svnqt which I guess
is their port
of rapidsvn. We could have a copy of svnqt in our repository
too.

If we will not have a copy of svnqt, we will most likely
write our own qt/c++
wrapper around svn anyway.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On Wednesday 14 March 2007 15:46, dukju ahn wrote:
> 2007/3/14, Matt Rogers <mattrkde.org>:
> > It's my general opinion that we need to avoid the
use of ioslaves for
> > SCM integration as much as possible. So the
subversion plugin should
> > use subversion's client API directly. As for CVS
and others, I'm not
> > entirely sure how that would work yet.
>
> OK. One thing that should be avoided is that KDevelop
UI will be
> blocked during subversion operations.
>
> Then I think using multithread is the only solution
now.

It depends how the subversion library is structured... if it
works with 
events/event loop, and can be integrated with our event
loop, it could be in 
the main thread; otherwise, multithreaded as you say.

Cheers,
Hamish.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel