Patch for preliminary Mercurial integration in kdevplatform

[Fabian Wiesel]

On Fri, 20 Mar 2009 12:56:18 +0300
Evgeniy Ivanov <pfx.kde at gmail.com> wrote:

Concerning "add to index".

> > This is quite interesting, but sounds very git-specific. Have you
> > any idea how to implement the functionality with any other VCS?
> 
> No, I don't know much about internal things of other VCS. [...]

You don't necessarily have to know about the internals. Only the public
interface / command-line tool. The problem is, it is part of the
interface, which means, that all the DVCSs have to implement it. If you
have no idea how to implement it, and neither I, chances are that it
shouldn't be part of the generic dvcs interface.

I think the whole index thing is git-specific, and should therefore be
removed from the generic interface.

> 
> > While we are at it, what about the reset()-function? From what I
> > understand, it seems to me as a mixture of checkout() and revert().
> 
> AFAIK Revert takes care about your history, [...] 
> - reset is a cleaning helper: no matter what you have in index or
> worktree - it will bring you, your history (etc) to the past (who did
> say you can't travel to the past?)
> [...]

There seem to be a slight misunderstanding, with checkout() and
revert(), I was referring to the IBasicVersionControl functions,
which, unfortunately, do not map directly to the git functions with the
same name.

I see, so reset() is similar to "hg strip". This can be implemented. I
only used git-reset in the same way as svn revert.


> > For what? An additional interface for distributed vcs? Certainly.
> > But what functions are essential for a DVCS? What does every DVCS
> > _have_ to implement? I don't think an "index" is part of that.
> 
> Yes,  an additional interface for distributed vcs and implementing
> basic interface in DVCS. 
> Mostly push, pull. Also functions to work with a history: rebase,
> revert, reset, checkout. Branching is a cool thing too (only with
> git/hg/bzr you can enjoy with it). 

I was trying to point out, that while there are a lot of cool features
in various DVCSs, many are not essential and bound to differ among the
various tools. I'd suggest to be rather cautious in adding said
features to the generic interface, as it may be next to impossible to
implement it with another DVCS.

> > isVersionControlled() is the smallest problem. The main problem is
> > that latency for calling external programs is too high for a
> > responsive UI. Caching doesn't solve the problem appropriately,
> > since it helps only on the second call.
> 
> Some optimizing still can be done.

> We can cache not only call to
> object, but use special cache strategy. Sorry my English, I don't
> know correct name of it: when processor get an instruction it always
> (most cases) takes some further instructions (since chances they will
> be called are high). [...]

It is called prefetching.

> [...]  So the thing that can be done: when any dvcs operation is
> requested we still check if we're in the repo, but we do it with our
> own code, which caches much more things, than one.
> If user requested a file operation, then something like "vcs
> ls-files" can be called to cache all files in the current directory.

As I said: "Caching doesn't solve the problem appropriately, since it
helps only on the second call". Prefetching doesn't change that. 
The UI has to be responsive from the first action on as first action
is the first impression.

Fabian