Patch for preliminary Mercurial integration in kdevplatform

[Evgeniy Ivanov]

On Sun March 22 2009 17:01:54 Andreas Pakulat wrote:
> On 22.03.09 11:55:19, Fabian Wiesel wrote:
> > On Fri, 20 Mar 2009 12:56:18 +0300
> >
> > Evgeniy Ivanov <pfx.kde at gmail.com> wrote:
> > > > 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
>
> Shouldn't checkout be moved to ICVCS as well? Unless I'm missing
> something with dvcs you don't "checkout" but you rather "copy" a remote
> repository, right?

No, with checkout you populate your working tree (working directory/etc) with 
specified commit content. Thus I can get anything I want from past or another 
branches. Most common usage of checkout in dvcs is to switch branches (but as 
I wrote it's more common, that just branch switching).
For remote repositories dvcs has something like clone, fetch and pull (also in 
git rebase can be used to get updates).


> > > > 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.
>
> +10 from me :) A given vcs-plugin can _always_ provide its own
> i<preferredvcsnamehere>.h interface header which other plugins can use
> then. The only downside would be interacting with scripting languages as
> for those the methods have to be slots (iirc)
>


I agree too.



-- 
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/20090322/f2230d61/attachment.sig>