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