Patch for preliminary Mercurial integration in kdevplatform

Fabian Wiesel fabian.wiesel at fu-berlin.de
Mon Mar 16 23:45:16 UTC 2009


On Mon, 16 Mar 2009 11:04:49 +0100
Andreas Pakulat <apaku at gmx.de> wrote:

> On 15.03.09 23:55:12, Fabian Wiesel wrote:

> [...] So maybe we should actually remove VcsLocation from the
> IBasicVC, splitting diff and the other methods that use it into two
> interfaces: IBasicVC and ICentralizedVC. 
> 
> So IBasicVC::diff() would take 2 KUrl's, IBasicVC::merge() would take
> 1 KUrl (as local location) and two revisions as start/end point for
> the merge-diff.

On second thought, don't think it is a good idea. For two reasons:
From an abstract point of view, a DVCS is the same as a CVCS. 
It only extends it by some distributed aspects. So, I'd say splitting
the interfaces is the wrong direction.

I fear, in the current form diff() and merge() can neither by CVCSs nor
by DVCSs be correctly implemented.

As it stands, it promises a diff between two VcsLocations.
So, what about file A at revision X and file B at revision Y?
Or even worse a diff between two different unrelated repositories?
Of course, technically this is possible, but it is quite pain to
implement, and probably not what you really want to provide.

This brings me back to the repository-as-an-object matter:
A particular checkout/repository is an instance, which contains
versioned files and directories, which have a diff()-function.
Both takes two VcsRevisions as argument and gives you the diff() of
those versions. I guess that is the functionality you wanted to
provide: A simple diff between two different versions of the same file,
either in repository or on disk.

merge() is simply a shortcut for diff() + patch, so the same applies.

Once more, I am  not suggesting changing the code in that
far reaching way. It's just a matter I have in the back of mind. 

Fabian





More information about the KDevelop-devel mailing list