Patch for preliminary Mercurial integration in kdevplatform

[Evgeniy Ivanov]

On Sun March 15 2009 03:11:33 Andreas Pakulat wrote:
> 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.

Why don't we use some new word (for VCS terminology): "Reset workspace" for 
example. Also there are some problems with "add".

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

Current solution is not so bad. We can have only common and minor actions in 
VCS menu: update, commit, add, remove, reset working copy, log. All this stuff 
is very easy to understand. And special menus might have more specialized 
stuff like rebase, branch, etc.
The idea is not to have just UI, but to make usage of any of plugin very 
common.  

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

Not at all (at least in git case, think the same is about Hg and Bzr).
In git any child to the repo root is a repository, so you can do not care 
about testing all parent dirs. Also there is a small known bug in git (it is 
if you think about "add" not in a git sense): now we check the dir and not the 
files (if file check is requested then parent dir is checked).

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

I thought about changing it, but was out of time. As we had discussion some 
long time ago: project file or any static object can contain git root, then 
isVersionControlled() for git will just check if root is parent directory of 
requested path. But still a problem with git's add (and actually remove): in 
git terminology it's still fine (add, remove for non-git objects we can simply 
ignore), but in our VCS terminology it's wrong. 


-- 
Best regards, Evgeniy.
Key Fingerprint: F316B5A1F6D2054FCD18B74A95400ABB1FE567A3

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20090315/81ec080d/attachment.sig>