Patch for preliminary Mercurial integration in kdevplatform

[Fabian Wiesel]

On Wed, 11 Mar 2009 13:41:31 +0100
Andreas Pakulat <apaku at gmx.de> wrote:


> Agree, I actually think we should just have "Diff of Uncomitted"
> which will simply show the changes you've done but not comitted -
> text subject to change when somebody has a better idea.

Well, that's definitely better.

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

In mercurial, that would be called backing out a changeset (backout).

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


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

The inefficency of this leads me to another question:
Wouldn't it be sensible to represent the local-checkout / repository as
an object?

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.



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

I will work on that. After, deriving from IDistributedVersionControl, I
noticed, that I lost lost too much functionality, which is implemented
in DVCSPlugin. So, I'd rather take the approach of changing 
DVCSPlugin, if there is no objection.


> 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 perforce needs: A directory, host, port, port, password, user, and
a file path. I think there is unified way to locate such a resource :).

> Note the interfaces are supposed to be usable by other plugins and
> (at some point in the future) also by scripts that drive KDevelop. 

As far as I can see it, changing VcsLocation to a KUrl would just mean,
that instead of git,hg,svn,monotone,bzr and darcs have to assemble a
remote url out of VcsLocation, perforce and cvs
have to de- and encode the information.

I'm not particular bent on removing VcsLocation, I just considered it
odd that an URL is used for storing a local file, while
information about the remote locations are stored separate fields.
Regardless, you won't hear about that any more from me as I have the
feeling I am making too much noise anyway.


Hope, I'll be worth the trouble,
  Fabian