Patch for preliminary Mercurial integration in kdevplatform

[Andreas Pakulat]

On 14.03.09 12:41:32, Fabian Wiesel wrote:
> On Wed, 11 Mar 2009 13:41:31 +0100
> Andreas Pakulat <apaku at gmx.de> wrote:
> > There's actually no "revert" in git, what revert does and is supposed
> > to do is revert uncomitted changes (which is git checkout -f). So
> > change the text to that might be a good idea.
> 
> I don't want to look like a wiseacre (which I have to admit I am).
> man git-revert
>        Given one existing commit, revert the change the patch
>        introduces, and record a new commit that records it. This
>        requires your working tree to be clean (no modifications from
>        the HEAD commit).

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. "revert"
means bringing back the "working copy" (which is the same as the local
repository for git) into a state where there's no uncomitted changes. The
above mentioned method reverts an already comitted change in the commit
history. In svn that would be a svn merge -c-<revision> + svn commit.
 
> > Seems like you stopped typing in the middle of a sentence :) 
> > We
> > definetly need to improve the texts and possibly also move some of
> > the actions out of the common menu. We just need to find a way to
> > express better what the action does, independent of what the
> > terminology for a given VCS is.
> 
> Well, I fear you will have to write half a sentence for almost every
> action. This part of what I missed to say. Granted, it makes it easier
> for auto-didacts, who will work only within kdevelop.
> 
> But you will require people to learn a different terminology and make it
> more complicated for people of different tool-sets using the same VCS to
> communicate with each other.
> That way beginners starting with kdevelop won't be able to use the
> tutorials in the web for the tool they use, because they simply might
> not know the correct term to look for. 
> 
> Also, consider the following situation: Someone more experienced
> relying mainly on command-line tools is going to advise someone
> new in the project. Since this newbie is very likely accustomed to an
> IDE with all the bells and whistles, the tutor will suggest KDevelop.
> How is the tutor not accustomed to the IDE going to instruct the
> newbie?
> Instead of just shouting "Context menu on the file, first select, git,
> then reset", the person has to stand up and have a look at the IDE, see
> whether it is a common vcs functionality and thereby placed under
> "Version Control" or not and how it is named ("Revert uncommited
> changes"?).

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. 

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

> > However supporting multiple VCS systems in the same project is simply
> > not feasable, at least not with the current implementations of the
> > VCS plugins. Some of them can't properly find out wether they should
> > handle a given file/directory or not.
> 
> It is perfectly feasible with the current interface (albeit somewhat
> inefficient).
> With IBasicVersionControl::isVersionControlled(), you can
> query which VCSs do have control over a file/directory (short:
> fsobject).
> When selecting a fsobject, query each VCS.
> When it claims control over said fsobject, add the appropriate
> context menu.
> For those fsobjects not under control of a VCS, you have to check the
> parent directory. Is it under control of the VCS you can add them to
> the VCS.

I actually meant not feasable because of this in-efficiency. 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)
 
> 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?

> As far as I can see, there is only a single instance of a VCS plugin,
> which has to derive the context each time from the location of the file.

Right, all of our plugins are single-instances.

> > Because not all VCS systems use urls to access remote repositories.
> > CVS doesn't and I'm told that perforce doesn't do this either.
> 
> Well, while CVS doesn't use an url, this doesn't prevent one to encode
> the CVSROOT + module + revison as one. Something along the lines of:
> CVSROOT=:pserver:user at server:/path/to/cvsroot module 1.34 ->
> pserver://user@server:/path/to/cvsroot/module#1.34

And then somebody uses a "#" inside its tag and we're going to start all
over. Apart from that we'd again invent a new protocol. Sorry, don't like
that at all.

> And perforce needs: A directory, host, port, port, password, user, and
> a file path. I think there is unified way to locate such a resource :).

Ok, so we could cover that one with a url, is this also the case for any
other VC systems? Also all that might come up in the next 5 years? 

> I'm not particular bent on removing VcsLocation, I just considered it
> odd that an URL is used for storing a local file,

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.

Andreas

-- 
You now have Asian Flu.