Patch for preliminary Mercurial integration in kdevplatform

[Fabian Wiesel]

On Mon, 16 Mar 2009 11:04:49 +0100
Andreas Pakulat <apaku at gmx.de> wrote:

> On 15.03.09 23:55:12, Fabian Wiesel wrote:
> Svn, CVS and git (though the latter not too much actually). So maybe
> I was spoiled because the ones I use most have very similar actions...

Well, the git-plugin I installed under eclipse is quite different from
the other menus (as git itself seems to be, too). Mercurial naming and
usage pattern is actually very much closer to SVN as git is.

> Hmm, gimme a day or two to review the current vcscommon code and think
> about this a bit [...]

Will do. At least on that matter :)

> > > I actually meant not feasable because of this in-efficiency.
> > 
> > Then for what reason? I do have two sub-menus for the two
> > concurrently operating VCSs. It bugs me, that I can use every
> > function, except those common functions.
> 
> Sorry, don't understand that question, I understand what bugs you
> though.

After rereading the passage, it seems to me I misunderstood you. If
performance is the performance is the problem, this can be solved.

> > Well, I assume performance wasn't the prime objective at this point
> > time.
> 
> Not a prime objective, but it was so bad that it affected efficient
> working with the context menu. You know we actually use kdev4 ;)

I do, too. That is why I started this. But I don't use the context
menu, because I cannot commit my changes to my local repository
with it :). I will work on the performance next weekend.

> > > Its actually a url, so not necessarily a local file, it could just
> > > as well be a file on a remote location - if the vcs plugin
> > > supports that.
> > 
> > That is the problem: the naming (localURL(), etc) and the
> > LocationType set by it suggest otherwise.
> 
> Granted this was written with mostly centralized vcs systems in mind
> because nobody that wrote the code had lots of experience with dvcs
> systems. So maybe we should actually remove VcsLocation from the
> IBasicVC, splitting diff and the other methods that use it into two
> interfaces: IBasicVC and ICentralizedVC. 
>
> So IBasicVC::diff() would take 2 KUrl's, IBasicVC::merge() would take
> 1 KUrl (as local location) and two revisions as start/end point for
> the merge-diff.
>
> What do you think?

This is going much further than I intended, but sounds good. I admit I
am seeing some problems in fullfilling the diff() and merge()
operations of IBasicVersionControl with mercurial as they stand, but
I'd give it some more time of tinkering around. Especially, when
changing interfaces, I'd have to look at more DVCSs.

VcsLocation is a perfectly okay, except in most DVCS (if not all) the
fields reserved for describing a remote location are much less fitting
a remote location than the field used for a local location.

Currently, I'd suggest removing the restriction, that an url is for a
local location and renaming the members accordingly.

Fabian