VCS Interfaces, round 3

[Matt Rogers]

On May 4, 2007, at 1:07 PM, Andreas Pakulat wrote:

> On 04.05.07 10:33:08, Matthew Woehlke wrote:
>> Matt Rogers wrote:
>>> On May 3, 2007, at 4:23 PM, Matthew Woehlke wrote:
>>>> Andreas Pakulat wrote:
>>>>> * Parameters for push/pull in the distributed vcs iface, no idea
>>>>> whats
>>>>>   needed there
>>>> This still needs to be addressed. The good news is that there are
>>>> no BC issues until a plugin is actually implementing it, so this
>>>> isn't urgent. (Similar to how we expect individual plugins will
>>>> create their own interfaces in addition to the shared ones, e.g.
>>>> IAegisVersionControl.)
>>>
>>> This assumption that there are no BC issues until a plugin is
>>> implementing it is incorrect. Being BC means that the interface
>>> _does_ _not_ change after releasing, even if there is nobody using
>>> it. BC is a contract between the interface writers and the users of
>>> that interface. Once we break that, we lose all trust, frustrate
>>> other developers, etc.
>>
>> Well, right now the interfaces exist and are not even remotely BC.  
>> So I
>> guess what I was saying is that we can slap a big "NOT BC - DO NOT  
>> USE
>> FOR NOW" label on IDistributedVersionControl until we have a  
>> plugin that
>> needs to implement it, at which point it will necessarily get some  
>> love
>> and we can make it BC going forward.
>
> Actually I'd like to remove that from the platform before the release
> unless we have at least one plugin implementing that interface. Its  
> much
> easier to add a new interface later on when there's not already an  
> "old"
> version. And adding a new interface is the only way to change the  
> API of
> an interface due to the fact that all methods are virtual.
>
>> straight-forward way, I think, is to do this up front in showLog()  
>> which
>> will invoke the widget after properly configuring it.
>
> +1 from me. As far as having extendable widget, all I say is MVC here
> (hello Alexander ;)
>
>>> Why do we have one interface that takes local paths and one that
>>> takes repo paths?
>>
>> Ask Andreas. :-) Personally I'd be in favor of dropping the one in
>> IBasicVC (that takes local paths), you can always still use local  
>> paths
>> indirectly with repositoryLocation().
>
> Uhm, actually I think I was a bit confused. Add certainly doesn't make
> the slightest sense to have in the repo interface. But remove does.
>
> Matt, the reason to have this split is that some VCS don't allow to  
> work
> on the repo directly (Matthew said perforce doesn't for example) and
> this way its much easier to communicate this to the API users. A  
> plugin
> that can't do stuff like remove() directly on repository paths simply
> doesn't implement the repository interface.
>
> Andreas
>

Ok, so that makes sense. Do the docs clarify this as well? If not,  
they should.

Matt