VCS Interfaces, round 3

Matt Rogers mattr at kde.org
Fri May 4 19:50:50 UTC 2007


On May 4, 2007, at 10:33 AM, 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.

I don't care if we don't keep BC while we're developing the  
interfaces. After we've released KDevelop 4.0 though, we _have_ to  
keep BC unless we want to be asses to anybody who uses our interfaces.


>
>> I missed a few things, so I have some questions.
>>
>> Why do we have log, and showLog?
>
> log() is for use in scripts, it allows you to do things like write a
> revision graph tool, ask for information about a file three versions
> ago, etc. With just showLog() this cannot be done.

scripts for what? command-line scripts? do you have a use case? this  
seems like something that is just there for the sake of being there,  
especially when we can add it later.

>
> We probably need to keep showLog() because some plugins have more
> information to present than others. Ideally we have a shared widget  
> that
> can be told how to display extra information, but to do that I  
> think we
> still must have something in the interface to set it up. The most
> straight-forward way, I think, is to do this up front in showLog()  
> which
> will invoke the widget after properly configuring it.
>
>> 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().
>
> Hopefully that helps! :-)
>

--
Matt






More information about the KDevelop-devel mailing list