About IBranchingVC...

[Andreas Pakulat]

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. If a plugin doesn't want to or is not able
to provide the remote actions it should be possible to have this,
without the plugin not being existant due to the fact that remote ops
are mandatory. In particular I don't think cvs can do such remote
things.

> >  What about things like ls or cat, I thought p4 doesn't allow to do
> > that directly?
> 
> cat() and ls() work in perforce without needing a valid client, i.e. I 
> know of no reason perforce will not implement IBrowsableVC.

Oh, I think I mixed browsable and repo :)

> >> 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.
> 
> Why does it need to know what VCS is being used, with the above? If you 
> form a sensible mapping and give a sensible branch name, it should Just 
> Work. In the case of say '/trunk/KDE' -> '/branches/KDE/3.5', this is 
> easy, the name is 'KDE/3.5' and the mapping is exactly what I already 
> wrote. The plugin simply may or may not need both.

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.

Last but not least, I just saw that VcsRevision needs some more work, It
needs to get a repo path - didn't we say that we want that? (Or at least
we thought about doing that). I'll send a new mail for that to not get
an extended thread again...

Andreas

-- 
It's lucky you're going so slowly, because you're going in the wrong direction.