Patch for preliminary Mercurial integration in kdevplatform

[Andreas Pakulat]

On 09.03.09 09:07:22, Fabian Wiesel wrote:
> Hello,
> 
> first, let me thank you for developing KDevelop. The new version looks
> very promising, especially the C++-parser is god-send.
> 
> I had a small itch to scratch: the current lack of Mercurial
> integration and decided to give it a go, essentially copying the
> Git-plugin and modifying it until it worked.

Sorry that you kinda wasted time, but there was already a basic plugin
in playground/devtools/kdevelop4-extra-plugins/mercurial (or hg??). You
should've asked here first :)

> Enclosed are two patches, first
> kdevplatform-rawinput-log-pushpull.patch
> makes some changes to the some non-mercurial classes as detailed below.
> The second one kdevplatform-mercurial.patch adds the mercurial plugin
> to the project.

I'll try to have a look at the patches in the next days. In the future
please post patches on reviewboard.kde.org.

> Now to some questions/remarks:
> 
> Is it a good idea to have a generic "Version Control" context-menu
> item and a separate one? I find it somewhat unintuitive. I'd suggest to
> have a separate menu for each VCS. This way, one can easily use two
> different VCS in one project (E.g Locally Mercurial, Remote SVN)

Yes, its important that users can use the same gui no matter which vcs
is working behind the scenes. For example most of the time I don't care
wether I'm commit/diff/log/update-ing a svn checkout or local git repo.
Of course stuff thats specific to a VCS should be in the context menu of
that VCS and we shouldn't have more than 1 vcs in the context menu for a
given file/directory. 

> Why is there the need for IDVCSexecutor? It mainly seems to
> duplicate the interface of DistributedVersionControlPlugin.

There is none, except that git plugin copied cvs plugin and that one was
a plain qt4 port of the kdevelop3 version which did it this way. IMHO
its a pretty ugly design.

> What does VcsLocation provide over KUrl?
> From a Mercurial point-of-view (and git, too) the location of the
> repository is simply an url: http-static://server/path,
> git://user:password@server/path, svn://server/trunk/stuff/
> In Mercurial employing KUrl as a repository
> location would mean simply passing KUrl::pathOrUrl() to the programm.

VcsLocation makes most sense when used with remote-repository vcs
system, i.e. where you have a local checkout from some remote
repository. So in case of git or mercurial you'd always use it as
"localUrl", i.e. with a local filesystem path. So if the
IBasicVersionControl::diff() method is called with a VcsLocation that is
a RemoteLocation then you probably want to return a 0pointer instead of
a real job.

If you have any suggestions how to improve the API to better fit for
systems such as git and/or mercurial I'm open to suggestions. The API
was mainly designed by two persons who have experience with CVS, svn and
perforce.

Andreas

-- 
It may or may not be worthwhile, but it still has to be done.