VCS Interfaces, round 3

[Matthew Woehlke]

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.

We could black-hole it (I guess that's the same difference, since a 
version has already been committed), although there isn't much to revive 
anyway. IOW make sure no one uses it until someone implements it. IMO 
there's no significant practical difference, so we're basically in 
agreement. :-)

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

I think this conversation just wandered off and got lost. I was asking 
about two instances of log() (at least, that's what I remember thinking 
I was doing? ;-)), although you're right, IRepoVC should have a remove().

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

Right. Actually... perforce *might* be able to emulate it with temporary 
clients (i.e. setting up a mapping but not actually doing the 'p4 
sync'), but I'd as soon not do such weird hacks in the back-end.

-- 
Matthew
Current geek index: 62%