Patch for preliminary Mercurial integration in kdevplatform

[Fabian Wiesel]

On Tue, 17 Mar 2009 11:48:32 +0100
Andreas Pakulat <apaku at gmx.de> wrote:

> At least thats what it provides with svn. As at least git doesn't
> support the 2 repository-diff methods it IMHO doesn't make sense to
> have it in IBasicVC. Note IBasicVC is supposed to be the "lowest
> common denominator" for all supports VCS.

I think, I have a solution. IBasicVersionControl has to be changed to
an abstract base class.

If I am not mistaken, all VCS can provide
the following function:
/**
 * Retrieves a file (locally or in the repository) at a given revision
 * and returns it in the VcsJob::result() as QByteArray? QString?
 * KMemFile?
 */

virtual VcsJob* cat(const VcsLocation& localOrRepoLocation, const
VcsRevision& rev) = 0;

Given this function, one can implement the current diff()
VCS-independent
in IBasicVersionControl. VCS can provide an optimised version by
overriding the function with their specific ones.

Since, we have the diff() function, implementing merge() is trivial.
Still, I'd agree that merge() is a candidate for removal
from the common interface, as it existence is more due to the work-flow
than an essential functionality of a VCS.

> I actually like the idea, because right now we simply have a
> procedural interface to the VCS designed mostly after the actual
> commandline tools. And I personally don't like that too much - at
> least not with that many functions.

Ultimately, I'd prefer to go in the direction of a more object oriented
approach, too. Maybe you remember my remark on why a repository is not
an object? At first, I thought it was straight forward text-book case
(Every noun a class: A working-directory/repository has versioned
objects (files and directories...). But after giving it some more
thought, I am not so sure about it anymore. The problem is, there is
already the project tree. And replicating almost the same directory
structure in the repository (or worse, when there are more VCSs:
repositories) seems somewhat bad design. On the other hand, the
relationship between repositories and directory trees can become quite
complex: A project tree may correspond to a
child-directory in a repository, or the root of the repository may
correspond to some subdirectory in the project-tree. One sub-tree may
be also under control of another VCS, one part of the sub-tree is under
control of another VCS, but not the current one (svn:external). 
Just food for thought :). 

Fabian