About IBranchingVC...
Andreas Pakulat
apaku at gmx.de
Fri May 18 21:07:06 UTC 2007
On 18.05.07 15:55:37, Matthew Woehlke wrote:
> Andreas Pakulat wrote:
> > On 18.05.07 14:26:39, Matthew Woehlke wrote:
> >> Andreas Pakulat wrote:
> >>> On 18.05.07 10:41:09, Matthew Woehlke wrote:
> >>> Why do you want to do that?
> >> Matt wanted perforce to implement IBranchingVC::branch() which requires
> >> a temporary directory *and* a temporary client (in fact, svn also needs
> >> a temporary directory if branching more than one path at once). I
> >> thought that logic was inconsistent with IRepositoryVC (which can, after
> >> all, be implemented, albeit less efficiently, with temporary directories
> >> and existing methods in IBasicVC). In fact, looking closer it seems
> >> perforce can "sort of" do server-side copies (not sure about moves) with
> >> the same caveat; you have to have a client associated with the files to
> >> do it (but apparently you don't need to actually sync down the files).
> >
> > But p4 being able to do this with some workaround doesn't justify the
> > merging of the 2 interfaces. [snip]
>
> Matt seemed to think otherwise, at least that was the impression I got
> if one assumes that his arguments for branch() would also apply to
> IRepositoryVC.
No, I tink what Matt complained about was that we'd remove the branching
iface just because 1 plugin wouldn't be able to implement it (or has
problems to do so). But the repository and the basic ifaces are really
different - IMHO.
> > Hmm, I'm convinced :) Lets see if Matt has more things to say, else I
> > think we've got branch + tag (with the mentioned changes to VcsMapping)
> > done in terms of specifying the iface methods.
>
> To confirm, branch() *and* tag()? Or just showTag()? I think tag() is OK
> with the same interface as branch() but wasn't going to push it if you
> disagreed.
branch() + tag() (and the show-versions too, of course).
Andreas
--
Good night to spend with family, but avoid arguments with your mate's
new lover.
More information about the KDevelop-devel
mailing list