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