Patch for preliminary Mercurial integration in kdevplatform

[Fabian Wiesel]

On Mon, 16 Mar 2009 09:18:49 +0100
Andreas Pakulat <apaku at gmx.de> wrote:

> On 16.03.09 09:01:07, Fabian Wiesel wrote:

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

Should I push a bit more? :)

> > 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.
> [...] So in fact git add works rather different from svn/cvs add and
> I personally think thats rather bad. 

Now, I see. I always used it the same way has in svn/hg and didn't
notice any difference.

But after reading that, I'd say all the more a reason to remove
that function as it not only duplicates functionality, but overlaps
with two different functionalities (add / commit). Hardly orthogonal.


> > What I am now thinking about is caching the dirstate / index. [...]
> 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). 

The best place to store that information would definitely be as close
to the user. But the current interface has two restrictions:
- it isn't very well suited for high latency calls:
    querying the status for one or for all files in mercurial (or git)
    takes roughly the same (relatively) long time, but the interface
    requires such queries. So with the current interface, caching has to 
    be done in the implementation of the interface. This isn't too bad,
    if it is generic enough.
- it is a one way communication:
    If something has changed, the only way the user of the interface
    will notice it, is by querying it. So, even if the latency would
    be low enough, it cannot store any information, as it can be
    outdated at any time.

I am not suggesting changing the interface at this point in time, but I
think, if the "caching" is done correctly, it can ultimately evolve to
a new interface. But at this point in time, forget what I've said, as I
can be completely wrong.

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

That would be my worker thread :)

Fabian