Patch for preliminary Mercurial integration in kdevplatform

[Andreas Pakulat]

On 15.03.09 23:55:12, Fabian Wiesel wrote:
> On Sun, 15 Mar 2009 01:11:33 +0100
> Andreas Pakulat <apaku at gmx.de> wrote:
> > On 14.03.09 12:41:32, Fabian Wiesel wrote:
> > I see and understand your points and maybe its just me personally but
> > I like it _a lot_ that I don't have to think about which VCS a
> > project is using most of the time when I'm working in Eclipse because
> > the things I use most of the time are always under "Team" and always
> > named the same. 
> 
> Which VCS are you using under Eclipse?

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

> > Apart from that, if we can't have that common vcs menu that also
> > means that our interfaces are completely void because those will have
> > the same problem (albeit being better documented, but you can have
> > whatsthis++statustip for menus too).
> 
> Separate vcs-menus are totally orthogonal to the questions of 
> -  the naming menu-items:
>     Even if they where all had the same names. One could use in
>     the same project different vcs concurrently. I currently have
>     KDevPlatform checked-out from svn and a hg repository. Without
>     any modification on the general code,I have the menus for
>     "Version Control", "Mercurial", and "Subversion". I have no idea,
>     to which VCS the common functions currently map
> - the interfaces:
>     Apart from the obvious reason for better code reuse, the interfaces
>     allow real IDE integration. Like automatic file adding or
>     marking of the file-status in the project browser.
> 
> I admit, a similar problem to the naming in the menu exists in the
> interface, but contrary to a user, a programmer can be expected to read
> the documentation.

Hmm, gimme a day or two to review the current vcscommon code and think
about this a bit (I'm almost sold on dropping that plugin and moving
actions into the vcs library along with every plugin supplying their own
menu).
 
> > 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.

> >  I mean the check is pretty quick for svn or cvs, but its horribly
> > slow for git (it makes the menu appearing take at least double the
> > time)
> 
> 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 ;)

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

Andreas

-- 
You had some happiness once, but your parents moved away, and you had to
leave it behind.