Patch for preliminary Mercurial integration in kdevplatform
Fabian Wiesel
fabian.wiesel at fu-berlin.de
Tue Mar 10 19:29:31 UTC 2009
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kdevplatform-mercurial.patch.gz
Type: application/x-gzip
Size: 9192 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20090310/5f05781b/attachment.gz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kdevplatform-rawinput-log-pushpull.patch.gz
Type: application/x-gzip
Size: 4020 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20090310/5f05781b/attachment-0001.gz>
More information about the KDevelop-devel
mailing list