Patch for preliminary Mercurial integration in kdevplatform

[Andreas Pakulat]

On 15.03.09 13:51:55, Evgeniy Ivanov wrote:
> 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".

Whats a "workspace"? How should the user know what workspace refers to
or what "reset" does. Reset to what? IMHO "Revert uncomitted
changes" is clear enough.
 
> > 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.

One thing you could easily do in the plugin is simply connecting to the
project-loaded signal in the constructor and then each time a project is
loaded check if you should manage it and internally store a map of
<IProject,GitRepoRoot> as accessing the IProject for a given file/url
should be relatively fast (its at most N set-lookups for N projects).

Andreas

-- 
You will give someone a piece of your mind, which you can ill afford.