VCS: Proposal for a change of arguments to remove(), checkout() and import()

Fabian Wiesel fabian.wiesel at googlemail.com
Mon Mar 30 18:43:07 UTC 2009


2009/3/27 Andreas Pakulat <apaku at gmx.de>

> On 27.03.09 10:50:23, Fabian Wiesel wrote:
>
> I just meant that you should use diff -u when creating the diff, which will
> use this format:
>
[...]
> which I personally find awkward to read. Its fine to post only parts of the
> whole patch.


Will do so next time.


>  > This may be a reason why VcsMapping came into existence, but it doesn't
> > negate the problems I cited.
> > What does one gain by batching all the checkouts? And is it sensible to
> > require all but one VCS to re-implement said capability?
>
> A VCS doesn't need to re-implement that capability. In fact it shouldn't
> and (unless I was drunk when writing it) Subversion only uses the first
> entry from the mapping and ignores everything else.
>

I think, that's the worst solution. Not only breaks the abstraction a
interface is supposed to provide, such an
implementation also falsely claims, that it executed the command I requested
correctly, while it didn't.
The only reason, why this hasn't failed fataly is, because all the callers
are just using the subset of the interface I suggested.

[...]  Its comparable to an svn:external that is set only locally inside
> that
> checkout.

The VcsMapping is a description of how to create 1 checkout directory from
> 1-n repository places.
>

Not only does it n checkouts, it also creates a references in the working
directory similar to svn:externals.
So, additionally of being specific to perforce, it seems to me a text-book
example of a non-orthogonal function.

Fabian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20090330/ec9d3bd7/attachment.html>


More information about the KDevelop-devel mailing list