About IBranchingVC...

[Matthew Woehlke]

Andreas Pakulat wrote:
> On 17.05.07 16:51:15, Matt Rogers wrote:
>> On May 17, 2007, at 4:38 PM, Matthew Woehlke wrote:
>>> Yes, but the semantics are different from how branching is done in  
>>> other
>>> VCS's. Also see above.
>>>
>> Why do we care about semantics in the interfaces? That should be up  
>> to the individual implementer of said interface to define. In CVS  
>> it's basically a label, in subversion it's a copy, in perforce it's a  
>> copy, in FooBarCoolVCS it's something else. And you know what, that's  
>> ok. Each VCS provides a branching feature.
>
> We don't care about the semantics in the plugin that much, but we need
> to find a proper API that fits at least the VCS'es we're currently
> talking of (cvs, svn and perforce). 

What Andreas said. :-)

> So for branch we'd have:
> 
> cvs
> ---
> branch-name revision remote-module(this one is optional)
> 
> svn
> ---
> source dest srcrev
> 
> perforce
> --------
> some-branch-object ?? (Matthew fill in please).
> 
> Keep in mind that these interfaces are meant to be unified among various
> VCS'es so that a client of the interface doesn't need to know which VCS
> he works with. I don't think thats possible to have for branch and tag
> because of the different semantics that the systems have. Of course I'm
> open to suggestions.
> 
> So for me having showTag() and showBranch() in IBranchingVC is ok, that
> way clients have a way to create a branch or tag and the plugin doesn't
> have to jump through hoops to do the branch/tag.
> 
> The only downside here is that the client of the interface doesn't know
> how the branch is called, but again this is vcs-specific information and
> thus the client would need to know which VCS he handles.

After thinking about it a while, I guess I'm OK with temporary 
directories and clients and so forth (as noted, if we go this route 
however we should fold IRepositoryVC into IBasicVC). What about this for 
branch()?

     virtual VcsJob branch( const QString& commitMessage,
                            const VcsMapping& mapping,
                            const VcsRevision& sourceRevision,
                            const QString& branchName ) = 0;

...and change VcsMapping to take 'source' and 'destination' instead of 
'repository' and 'local' (source == repository, destination == local)? 
We then doc branch() such that the plugin may ignore either the mapping 
destinations (i.e. CVS?) or the branch name (SVN). This would work for 
perforce and svn (for perforce, a temporary client name would be used, 
e.g. 'vcs.kdevplatform.20070518.102413')... not sure about CVS or others.

For perforce and svn, the same signature should work for tag() also. The 
most incompatible part about tags is that they are not checked out the 
same way, e.g. in perforce a tag is a special way of specifying a 
revision, but the paths you are actually checking out are what the tag 
(label) was created against. For svn of course (and I think CVS?) you 
check out the tag itself. Does a branch potentially pose the same problem?

-- 
Matthew
Excessive obscurity: -5