Patch for preliminary Mercurial integration in kdevplatform

[Fabian Wiesel]

On Sun, 15 Mar 2009 13:51:55 +0300
Evgeniy Ivanov <pfx.kde at gmail.com> wrote:

> On Sun March 15 2009 03:11:33 Andreas Pakulat wrote:

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

I agree with Andreas, that "Revert uncommitted changes" is probably
better. I fear you have qualify practically every command. Except AFAIK
for "add" and "delete". What do you think are the problems with "add"?

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

Except it doesn't work with mixed VCSs.

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

I just don't see, how by separating the commands of a VCS in different 
sub-menus helps making the usage common. Placing the commands under
one menu named after the VCS itself is a generalisation a person is
quite capable of. Especially since the person is already confronted
with the name of the VCS, when creating/importing the project into
KDevelop.

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

That's why I said the parent dir. Git (and mercurial, too) however, do
check all the parent dirs, in order to determine we

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

AFAIK, git add, svn add, and hg add do all the same: Adding new files to
be commited. The manual of git is just a bit more verbose and calls it
adding to the "index". The other programs just don't name the object,
which stores the meta-data before commit. Same with rm.

> I thought about changing it, but was out of time. [...]. 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. 

The first step I took to speed it up was implementing the
isValidDirectory() check without calling the external programm. I think
the same could be done for git. 
What I am now thinking about is caching the dirstate / index.  A worker
thread can pull in the dirstate information and keep the cache
consistent by monitoring the .hg directory for changes. Probably the
same could be done for git (.git-directory). I try to keep it generic
enough, so it can be reused.

Fabian