Patch for preliminary Mercurial integration in kdevplatform

[Gabor Garami]

I think a per-VCS menus isn't a best way. I use it in NetBeans and I
always have a pain when i use it. First, kdevelop knows which version
control stuff is being used in the current project, so I don't think a
per-VCS submenu is really needed, but a menuitem collection..
I mean the VCS plugin defines somehow the supported GUI commands
(standard GUI commands as well), and the GUI builder adds them
dynamically to the popup menu (and to main menu ofc) For example, svn
has a checkout, commit, diff, log, merge, status and remove commands,
git additionally has branch and tag commands. So the two plugin can
return with a collection of supported actions, and the
implementation-dependent details (different commands for hg and git,
or different pop-up dialogs) are hidden in called functions, not on
GUI. If the plugin returns with a collection of KAction
(KActionCollection?) the GUI builder has an easy work: walk a
collection and add items to correct places.

Garami Gábor
hrgyster at gmail.com



2009/3/10 Fabian Wiesel <fabian.wiesel at fu-berlin.de>:
> 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.
> What should work? status, commit, init, clone, log. Somewhat limited:
> RevHistory, push, pull
>
> 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.gz
> adds the mercurial plugin to the project.
>
> First, DVCSjob is changed from parsing the output for lines and later
> rejoining them to a single string to simply accumulating a QByteArray.
> This allows the external program to output binary data.
> The old DVCSjob::output() casts the binary output into a QString,
> a new DVCSjob::rawOutput() function provides access to the raw
> QByteArray.
>
> IDVCSexecutor::parseOutput() has been changed to accept a QByteArray for
> the same reason.
>
> DistributedVersionControlPlugin now forwards log(), push() and pull()
> calls to the IDVCSexecutor.
> The push() and pull() signatures have been
>  changed to the same as DistributedVersionControlPlugin. The
>  VcsLocation is left empty, as I have no idea, where one has to
>  get this option. In case of mercurial (and AFAIK git, too) it is
>  possible to store a default-push/pull location. One has to manually
>  configure it, and then push/pull works, provided there are no
>  conflicts.
>
> Hope, it is of some use.
>
> Now to some questions/remarks:
>
> Is it a good idea to have a generic "Version Control" context-menu
> item and a separate one for the special 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)
>
> Why is there the need for IDVCSexecutor? It mainly seems to duplicate
> the interface of DistributedVersionControlPlugin.
>
> What does VcsLocation provide over KUrl?
> From a Mercurial point-of-view (AFAIK git too) the location of a
> repository is simply an url: http-static://server/path,
> ssh://user:password@server/path, svn://server/trunk/stuff/,
> git://server/repo.
> In Mercurial, employing KUrl as a repository location would mean
> simply passing KUrl::pathOrUrl() to the programm.
>
>
> Thanks for you patience in advance.
>
> Your inquiring,
>  Fabian
>
> _______________________________________________
> KDevelop-devel mailing list
> KDevelop-devel at kdevelop.org
> https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
>
>