Patch for preliminary Mercurial integration in kdevplatform

[Andreas Pakulat]

On 11.03.09 12:28:01, Fabian Wiesel wrote:
> On Tue, 10 Mar 2009 20:48:55 +0100
> Andreas Pakulat <apaku at gmx.de> wrote:
> 
> > I'll try to have a look at the patches in the next days. In the future
> > please post patches on reviewboard.kde.org.
> 
> Will do so. How am I supposed to proceed, when I have a superseeding
> (larger) patch? Should I wait until the previous has been reviewed?

I think you can update an existing review on reviewboard.kde.org with a new
patch. No need to wait for reviews.
 
> > Yes, its important that users can use the same gui no matter which vcs
> > is working behind the scenes.
> 
> Well, it matters, because the terms used in the different VCS differ.
> 
> First the little things: Currently in the common menue, there is
> "Compare to Base/Head".
> I had to look them up in the svn manual, because after 3 years not
> actively using svn, I couldn't remember, what Base and Head stand for.

Agree, I actually think we should just have "Diff of Uncomitted" which will
simply show the changes you've done but not comitted - text subject to
change when somebody has a better idea.

> But this is merely a inconvenience. More critical are the false
> friends: "svn/hg revert" <-> "git revert".
> You and me would expect "revert" to reset the state of a file/directory
> to the last commited version. A git-user would expect "revert" to revert
> a certain changeset (in git-terms "patch"), the command, which would
> reset the files to the commited state would he expect to be called
> "reset".

There's actually no "revert" in git, what revert does and is supposed to do
is revert uncomitted changes (which is git checkout -f). So change the text
to that might be a good idea.

> If I understand git correctly, "git pull" does what "hg fetch" does and
> "hg pull" does what "git fetch" does.
> And these are only the conflicts between two VCS. I have no knowledge
> about bzr, monotone, or darcs, but this could get quite messy.
> 
> Trying to unify it to a common terminology may seem 

Seems like you stopped typing in the middle of a sentence :) We definetly
need to improve the texts and possibly also move some of the actions out of
the common menu. We just need to find a way to express better what the
action does, independent of what the terminology for a given VCS is.

> >  [...] we shouldn't have more than 1 vcs in the
> > context menu for a given file/directory. 
> 
> So, when using a mercurial repository for tracking my local changes,
> and subversion for the remote ones, I am supposed to switch back to
> console? Which vcs should kdevelop integrate, and which neglect?

I don't know how mercurial does this, but at least with git there's only
files from the git repository in your project. Currently we have code to
guess the VCS system and you can edit your kdev4 project files to change
it. A GUI option will be done sooner or later. 

However supporting multiple VCS systems in the same project is simply not
feasable, at least not with the current implementations of the VCS plugins.
Some of them can't properly find out wether they should handle a given
file/directory or not.

> > There is none, except that git plugin copied cvs plugin and that one
> > was a plain qt4 port of the kdevelop3 version which did it this way.
> > IMHO its a pretty ugly design.
> 
> Ah, I see. So the way to go would be to implement the 
> IDistributedVersionControl interface directly? Or (after a rewrite)
> deriving from DVCSPlugin?

I think so, yes.

> > VcsLocation makes most sense when used with remote-repository vcs
> > system, i.e. where you have a local checkout from some remote
> > repository. 
> 
> And how does KUrl doesn't fit the bill for remote repositories
> locations as well for local-ones? Like git://user:password@server/path,
> svn://server/trunk/stuff/

Because not all VCS systems use urls to access remote repositories. CVS
doesn't and I'm told that perforce doesn't do this either.

Note the interfaces are supposed to be usable by other plugins and (at some
point in the future) also by scripts that drive KDevelop. 

Andreas

-- 
You're growing out of some of your problems, but there are others that
you're growing into.