Patch for preliminary Mercurial integration in kdevplatform

[Evgeniy Ivanov]

On Thu March 19 2009 00:04:50 Fabian Wiesel wrote:
> 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?

No, I don't know much about internal things of other VCS. But if you're 
interested in what git has internally you can read part2 of their tutorial.

> 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, thus if you revert some commit it 
should stay in history and you will get another one with "reverted state" of 
that one. And reset allows you to throw away some parts of history (sure with 
objects, etc). So if your last commit was a trash you can simply cat it off. 
In comparison with revert, reset changes your index and working tree (revert 
doesn't and require you working tree to be clean). And git-checkout does the 
only thing: it brings commit content to your working tree.
If to sum up: 
- revert helps you to create commit with "undo" of some previous commited 
changes. It's the correct way if you work in a team, which already uses your 
commits.
- 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?)
- checkout simply changes your working tree with new content (any path or even 
the whole commit from the past/abother branch etc).


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

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

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

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).
In our case when we check isValidDirectory() backend (git, hg, etc) checks all 
directories until root. And for now we can check only one item, but many 
others are checked.
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 for hg/bzr: we can directly call their python code and use it in way we 
want. As for git libgit2 is not finished yet (but still some their code might 
be reused). I hope they will finish it during this summer of code.

And it's just a quick thoughts. I think if we will work on it we will be able 
to write good API for caching, so our DVCS integrations will rock like our C++ 
support.


-- 
Best regards, Evgeniy.
Key Fingerprint: F316B5A1F6D2054FCD18B74A95400ABB1FE567A3

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20090320/defd0110/attachment.sig>