Patch for preliminary Mercurial integration in kdevplatform

[Fabian Wiesel]

On Tue, 10 Mar 2009 20:48:55 +0100
Andreas Pakulat <apaku at gmx.de> wrote:

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

Will do so. How am I supposed to proceed, when I have a superseeding
(larger) patch? Should I wait until the previous has been reviewed?

> Yes, its important that users can use the same gui no matter which vcs
> is working behind the scenes.

Well, it matters, because the terms used in the different VCS differ.

First the little things: Currently in the common menue, there is
"Compare to Base/Head".
I had to look them up in the svn manual, because after 3 years not
actively using svn, I couldn't remember, what Base and Head stand for.
I'd say, it isn't a good sign, that acquainted with the underlying VCS
has to lookup the manual for another VCS. Still, I am not sure, how it
should mapped to Mercurial.
But this is merely a inconvenience. More critical are the false
friends: "svn/hg revert" <-> "git revert".
You and me would expect "revert" to reset the state of a file/directory
to the last commited version. A git-user would expect "revert" to revert
a certain changeset (in git-terms "patch"), the command, which would
reset the files to the commited state would he expect to be called
"reset".
If I understand git correctly, "git pull" does what "hg fetch" does and
"hg pull" does what "git fetch" does.
And these are only the conflicts between two VCS. I have no knowledge
about bzr, monotone, or darcs, but this could get quite messy.

Trying to unify it to a common terminology may seem 

>  [...] we shouldn't have more than 1 vcs in the
> context menu for a given file/directory. 

So, when using a mercurial repository for tracking my local changes,
and subversion for the remote ones, I am supposed to switch back to
console? Which vcs should kdevelop integrate, and which neglect?


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

Ah, I see. So the way to go would be to implement the 
IDistributedVersionControl interface directly? Or (after a rewrite)
deriving from DVCSPlugin?


> VcsLocation makes most sense when used with remote-repository vcs
> system, i.e. where you have a local checkout from some remote
> repository. 

And how does KUrl doesn't fit the bill for remote repositories
locations as well for local-ones? Like git://user:password@server/path,
svn://server/trunk/stuff/

One can easily differentiate between the two using KUrl::isLocalFile()
instead of VcsLocation::type() == LocalLocation.  I'll come back to
this later.

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

At the current point, I don't see any problems with the API itself, the
functionality provided by the interface is perfectly serviceable by
mercurial.

I currently don't have the overview, so I am not quite sure how the
the other parts outside of the IDistributedVersionControl plugins are
supposed to interact with them, and especially how the various possible
remote repositories are to be managed.

Thanks for your explanations, I hope I will be more of a help than a
burden in future,
  Fabian