Patch for preliminary Mercurial integration in kdevplatform

[Andreas Pakulat]

On 16.03.09 09:01:07, Fabian Wiesel wrote:
> 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:
> > 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.

I'm starting to change my mind on this and am actually wondering right now
wether vcscommon exists solely to demonstrate that our IBasicVC API does in
fact work cross-VCS (i.e. same API for all VCS).... I haven't changed my
mind completely though :)
 
> > 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.

No, actually git's add is a two-step thing for files that are not yet
version controlled: Make them version controlled and add them to the index
which means they'll be part of the next git commit. However add is also
used for just the second part of that two-step if the file is already
version controlled and has any changes in it. Its also a mean of saying
"Commit any changes in file foo with the next commit, except whatever I
change after calling git add". So in fact git add works rather different
from svn/cvs add and I personally think thats rather bad.
 
> > 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.

Or svn, this is some of the things that we'll want anyway to show the
current state of files in some places (like the project tree). Oh and you
don't necessarily need a separate thread for this as your dvcsjob itself
could do it threaded and your monitoring would simply kick off a new job
each time something changed.

Andreas
 
-- 
You will be surprised by a loud noise.