[GSoC Proposal] Better Version control front-end

Miha Čančula miha.cancula at gmail.com
Tue Mar 30 17:48:42 BST 2010


Dne ponedeljek 29 marca 2010 ob 12:23:01 je Andreas Pakulat napisal(a):
> On 29.03.10 10:49:50, Miha Čančula wrote:
> > There are a few (maintained or not) plugins for version control in
> > KDevelop, which mostly provide their own GUI for different tasks. There
> > is also a framework composed of interface classes. What I would like to
> > do is a unified front-end for them. It would display features common to
> > all VCS's, and also some specific views. Those would be enabled based on
> > what interfaces the specific plugin implements.
> 
> Thats not entirely true, all vcs plugins use the review-toolview for
> reviewing commits and comitting them. In the same way all of them should be
> using the KTE interface to show the blame/annotate information. And we also
> have a log-viewer already that works independent from the VCS.
The review toolview is very useful, especially the inline showing of changes, 
but could use a bit of UI polishing. 
> 
> > One part would be directly related to version control features. It could
> > be done as a single ToolView with tabs, or one ToolView per feature (my
> > 
> > favourite), or perhaps even in its own window. Those windows/views would 
be:
> >  - Modified files monitor (all)
> 
> This is already started in playground (IIRC) by Aleix, not sure what the
> state is and how it works.
I am in the process of going through all the plugins in playground. I'll see 
how far is it. Anyway, the review toolview already shows a list of modified 
files.
> >  - Diff viewer (all)
> 
> It would be good to re-use the existing review-plugin for that, as it shows
> the diff inline in the file.
I agree, the inline view is powerful now as it is. The widget itself could use 
some UI love. 
 
> >  - Branch viewer/manager (branching VC)
> >  - Local and remote repository tracker (distributed VC)
> 
> These are some of the things really missing, especially since they enable
> creation of project from a VCS.
I'm sorry but I don't really understand what you mean here.
> 
> > Additionaly, I would add "Import from KDE SVN" and "Import from
> > Gitorious" options next to "Import existing project". This could be
> > paired with one-click exports of new projects to the same servers.
> 
> I'm not sure how much sense these "shortcuts" make as its basically just
> the url-typing you save and eventually not even that as you'll have to
> provide the protocol anyway.
It would simplify making a quick patch to something in KDE's SVN tree, 
especially combined with patch export. I don't know how common a use case this 
is, but it would be easier that checking out from the command line and then 
imporing.

Apart from what was already mentioned, are there any other VCS features that 
would benefit from a new interface? I use little more that commiting and 
updating, but I suppose there might be some features that I don't use but 
would be useful to others. 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop/attachments/20100330/46af4861/attachment.sig>


More information about the KDevelop mailing list