About IBranchingVC...

[Matthew Woehlke]

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

Possibly. I'm continuing the conversation with Matt Rogers at least as 
much as replying to you.

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

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

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

-- 
Matthew
Excessive obscurity: -5