Patch for preliminary Mercurial integration in kdevplatform

[Evgeniy Ivanov]

Hello,

Sorry, until Weekends I will not be able to review patches and commit.
Maybe someone else could do it.

On Mon March 9 2009 11:07:22 Fabian Wiesel wrote:
> Hello,
>
> 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.

Should be fine.

> 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.

A dialog can be shown. But it's fine IMHO.

> 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)

There was some discussion in the mailing list at the end of summer / begin of 
autumn. Main reason was to unify menu items (see VcsCommonPlugin).
I don't like it much, but maybe it's correct for current plugins.

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

Not at all: it is like a proxy used by DistributedVersionControlPlugin, so you 
don't have to use dialogs, etc in the DVCS plugins directly, you just have to 
implement their functionality.

> 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.

Not sure I understood. KUrl is the only proper way to provide path/url. Any 
path/url in the interface must be KUrl. Executors should use it too, but it 
was my mistake to use QString there.

-- 
Best regards, Evgeniy.
Key Fingerprint: F316B5A1F6D2054FCD18B74A95400ABB1FE567A3

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20090310/e7c101f7/attachment.sig>