Patch for preliminary Mercurial integration in kdevplatform

Fabian Wiesel fabian.wiesel at fu-berlin.de
Sun Mar 22 17:25:24 UTC 2009


On Sun, 22 Mar 2009 19:32:00 +0300
Evgeniy Ivanov <pfx.kde at gmail.com> wrote:

> On Sun March 22 2009 18:38:20 Fabian Wiesel wrote:
> >
> > That is git-checkout. IBasicVersionControl::update() is the
> > corresponding interface function. As I said, git unfortunately
> > decided to map the terms employed by Subversion on different
> > operations.
> >
> 
> Update() is a "pull" IMHO. 
> Update should get new changes from remote
> repo and update your history/working tree.

That may be the way subversion works, so you might
expect that, but that doesn't mean that it is right.

From a DVCS point-of-view the update()-function would realise two
separate operations in one call:
-   Pulling the change-sets/patches from a (default) remote repository
  to the local one, 
-   Integrating the change-sets into the working-directory


This is not orthogonal. It may be the way you want to represent it to
the user as it is more convenient (see git-pull), but it shouldn't be
the way it is implemented, as it is bad design.

Also have a look at the interface description:
"fetches the latest changes from the repository, [...]".
What is "the repository" in a DVCS, when not the local one?
You can define one remote repository to be "the repository", but that
is purely optional. 
Also, it lets you define the revision you want to "update to".
Admittedly, in this context the term "checkout" from git is more aptly
chosen, but that doesn't change the signature.

> Checkout is a pure local thing.

checkout: "Checks out files or dirs from a repository [...] into a local
directory hierarchy."

Notice "a" repository. One at the users choice as indicated by expecting
a VcsMapping. What has a VcsMapping to do with just local operations?
And how am I supposed to specify a revision like update() lets me?

I think, you are concentrating too much on the names instead of looking
at the signature.

Fabian





More information about the KDevelop-devel mailing list