About IBranchingVC...

[Andreas Pakulat]

On 18.05.07 10:41:09, Matthew Woehlke wrote:
> Andreas Pakulat wrote:
> > 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).

Did I miss something in the discussion? Why do you want to do that? What
about things like ls or cat, I thought p4 doesn't allow to do that
directly?

> 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.

But then the client has to know which VCS is used, which we should
avoid, IMHO. IMHO we can live with just 2 gui methods for branch and
tag, given that these things differ that much in the various VCS (and
thats only the 3 we're looking at atm). 

> 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?

In CVS a tag is just a named revision as in p4 and the same is true for
a branch, i.e. you use something like 

cvs co -r branchname module

Andeas

-- 
Beware of a tall blond man with one black shoe.