About IBranchingVC...

[Matthew Woehlke]

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. Anyway I'll leave things as they are unless Matt wants to 
complain, especially since the work-around for IRepositoryVC methods is 
obvious (if potentially slower, but then if perforce wants to expose the 
stuff that would make this faster then IMO it should implement a 
worked-around IRepositoryVC after all :-)).

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

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.

Anyway I have the changes mostly ready over here, just the doc needs 
some work (as usual ;-)).

> [snip[ I'll send a new mail for that

Ok, I'll wait. :-)

> to not get an extended thread again...

For us, this thread is short so far. :-)

-- 
Matthew
Excessive obscurity: -5