About IBranchingVC...

[Matthew Woehlke]

Matt Rogers wrote:
> On May 17, 2007, at 4:38 PM, Matthew Woehlke wrote:
>> Matt Rogers wrote:
>>> On Thursday 17 May 2007 14:24, Matthew Woehlke wrote:
>>>> - clarify what branch() and tag() do in a way that is favorable to a
>>>> perforce implementation
>>> hmm, also no. why should our interfaces favor perforce or any  
>>> other version
>>> control system, subversion and cvs included?
>> They have to, if they are going to be generic interfaces. :-) (Well,
>> really they have to be defined in a way that lets as many VCS's as
>> possible implement them.)
> 
> Exactly, hence my question as to why we should clarify.

Right now the definition of branch() doesn't really work for perforce. 
So if perforce is to implement IBranchingVC() then it needs branch() to 
be defined in a way that allows it to do so. Does that make sense?

>> The problem is for perforce to implement a "generic" branch, it has to
>> invent a temporary client, which I consider to be 'an ugly hack' (keep
>> in mind that once you do this, the name of said client lives forever).
>> When I brought this up previously, Andreas agreed that we would rather
>> not do this sort of thing. Given what must/should be done to create a
>> branch in perforce, I feel that the best place for the perforce plugin
>> to implement branch() is in IPerforceVersionControl.
> 
> Then you do it there, in the plugin, and the plugin doesn't implement  
> IBranchingVCS

Isn't that what I said? :-) This would be one option, but you've got me 
wondering about doing it your way (temporary directories, etc). In which 
case IRepositoryVC should be folded into IBasicVC. I'm going to draft 
another attempt at IBrowsingVC in reply to Andreas' reply to the 
previous message; stay tuned.

>> Or we could make branch() look like:
>>
>> branch( <what to branch>, <where to put it>,
>>          QString nameOfBranch,
>>          QString nameOfTemporaryClient );
>>
>> ...where VCS's may ignore the last two arguments. I would probably do
>> something similar with tag() in that case, take a source, destination,
>> and name, where one of the latter two is ignored.
> 
> No, we don't want to do that because then branch and tag become  
> perforce specific and then being generic goes right out the window.

Not really, and JFTR we already have an interface with a 'might be 
ignored' parameter: IBasicVC::log().

-- 
Matthew
Excessive obscurity: -5