Patch for preliminary Mercurial integration in kdevplatform

[Fabian Wiesel]

On Tue, 17 Mar 2009 13:31:59 +0300
Evgeniy Ivanov <pfx.kde at gmail.com> wrote:

> On Mon March 16 2009 23:52:26 Fabian Wiesel wrote:
> > I think, that is a peculiarity of git (or should I say another?).
> > [...] If I understood Andreas correctly, git simply adds another
> > meaning to ad [...]:
> Not at all. Result of git add is an object representing file in git 
> repository. [...] Another add-objects will become dangling and will
> be removed in some amount of a time (AFAIK depending on your
> settings). [...]

This is quite interesting, but sounds very git-specific. Have you any
idea how to implement the functionality with any other VCS?

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

> I agree that items should be named in one way, but I like N-menus
> instead of one (I fully support your initiative to push Andreas to
> the new (which is actually old) layout of VCS menus :) ).

Well, I think we are on our way :).


> > I have the feeling, that several people think, that DVCS are
> > much more different from CVCS than they really are. In essence, they
> > simply are local VCSs (-> init) with the possibility of pushing
> > changes to a passive receiver (push), or pulling them from another
> > (pull). Due to their distributed nature, they have to understand
> > parallel branches of changesets. This lead to the advent of in-tree
> > branches.
> 
> That was one of the reasons.

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.


> > [...] VcsCommonPlugin cannot cache it in a sensible way, as it
> > doesn't know, when something has changed in the repository. This is
> > VCS specific.
> 
> [...]
> But agree you can do caching in isValidDirectory()
> (isVersionControlled). It doesn't look very hard with my suggestion
> about add/remove signals.

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.
A vcsStatusInfoChanged()-signal might sound like a solution, but the 
problem is, for appropriately signalling the change, the VcsPlugin has
to know, what has changed. It therefore must have stored previous
state. This would be a duplication of information. So, with
the current design, I think the best approach is that the VcsPlugin
stores the information itself.
Still, such signalling is necessary, since we want to keep the GUI
up-to-date.

Fabian