Patch for preliminary Mercurial integration in kdevplatform

[Fabian Wiesel]

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:

> That is _not_ the same as svn revert and thus not the same as what the
> current "revert" operation in our API is supposed to be doing.
Exactly. I didn't want to say otherwise. The API is perfectly
well defined. I thought, that you where referring to the
word "revert", not the function revert().

> 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? All the common function of
Mercurial are having the same name as on the command line. There are
some more obscure ones, which I have never used so I cannot guarantee,
that his applies for all ones. 
update  maps to hg update, which btw. is false friend with svn
update
I installed the Git-Plugin and the commands seem to map to the command
line arguments of git.

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

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

>  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.
Should it be such a concern, I could give it some time.

> > The inefficency of this leads me to another question:
> > Wouldn't it be sensible to represent the local-checkout /
> > repository as an object?
> 
> What would that object contain? What API would it provide?

Well, IBasicVersionControl, IDistributedVersionControl would the API.
It could preserve the status information about the checkout-directory /
repository, so that one doesn't have to start a process for each and
every query on a file (which are two for a right click, btw)
I am perfectly aware, that you already can do that in the plugin. The
problem, however, is that you lose the context, which you have
to recover from the location of the file.

> And then somebody uses a "#" inside its tag and we're going to start
> all over.

That is a valid point.

> 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. So, I assume you are okay with some
renaming and the usage of an url() as a VcsLocation. I'd be perfectly
happy with that.

Fabian