VCS Interfaces, round 3

[Andreas Pakulat]

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

-- 
You will be honored for contributing your time and skill to a worthy cause.