About IBranchingVC...

[Matt Rogers]

On May 17, 2007, at 4:38 PM, Matthew Woehlke wrote:

> Matt Rogers wrote:
>> On Thursday 17 May 2007 14:24, Matthew Woehlke wrote:
>>> How exactly is branch() supposed to work? In perforce, a  
>>> "tag" (label)
>>> requires the source files to be checked out, while a branch()  
>>> requires
>>> the destination to be in the view (branch() == copy() except  
>>> somewhat
>>> more sophisticated). Also there is a "branch" object that would
>>> (should?) be created in this case. Also labels in perforce need a  
>>> name
>>> (no surprise here).
>>>
>>> In svn AFAIK both branch() and tag() are synonyms for copy(). I  
>>> don't
>>> know how things work in CVS.
>>>
>>> Options:
>>> - move branch() to IRepositoryVC and drop tag()
>>
>> nope, people need to tag and branch things for certain VCSs but  
>> not all of
>> them require branching or tagging. Branching and tagging need  
>> their own
>> interface.
>
> Clarification: tag() would move to IFooVC, e.g. ISubversionVC, ICvsVC,
> etc. The generic interfaces are for things that can be shared between
> two or more VCS's.
>

tag() is shared by at least two VCSs, if not more.

>>> - perforce doesn't implement IBranchingVC
>>
>> nope, because it obviously does some sort of branching
>
> Yes, but the semantics are different from how branching is done in  
> other
> VCS's. Also see above.
>

Why do we care about semantics in the interfaces? That should be up  
to the individual implementer of said interface to define. In CVS  
it's basically a label, in subversion it's a copy, in perforce it's a  
copy, in FooBarCoolVCS it's something else. And you know what, that's  
ok. Each VCS provides a branching feature.


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

>
>>> - drop IBranchingVC altogether; plugins will expose the VCS's  
>>> native flavor
>>
>> nope. We can have an interface for branching, it's a universal task.
>
> If it's a "universal task" then IBranchingVC has no business existing
> and branch() belongs in IBasicVC. IIRC IBasicVC is the only non- 
> optional
> interface. So... your preference? ;-)
>

Branching needs to be optional for those distributed version control  
systems (think git and darcs here) that don't require branching.   
IBasicVC should describe the basic functionality a version control  
should have. That is why it is non optional.


>>> In any case, "branches" can still be done using copy() from  
>>> IBasicVC for
>>> the generic case, otherwise plugins are expected to expose the VCS's
>>> native flavor of this.
>>
>> branching is a term that is universally understood. It has an  
>> equivalent for
>> nearly all version control systems. (the exceptions being the  
>> distributed
>> ones like git or darcs, which probably wouldn't implement the  
>> IBranchingVC
>> interface anyways). If needed, the VCS plugin should take the  
>> steps needed to
>> make a branch or a tag, even if we use a temporary directory for it.
>
> 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

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