[RFC] Workingstyle of different VCS systems

[Matthew Woehlke]

Andras Mantia wrote:
> On Friday 13 April 2007, Matthew Woehlke wrote:
>> This 
>> is something else I would like KDevelop to help support. With the
>> Grand Unified Interface we're currently discussing, you can write a
>> fully-featured, backend-agnostic VCS UI.
> 
> I asked in the beginning if this is the goal or not and I understood 
> that this is not the goal of the interfaces.

Well if it is not, then /I/ am confused, and we need to re-think Vic's 
project, which I was assuming would leverage this. See also the thread 
on kde-devel (which I have tried twice, unsuccessfully, to cross-post here).

>> Why should I not be able to write a script that says 'do this merge,
>> pop up the UI for anything that needs to be resolved, then commit
>> it'?
> 
> Will you write it? ;) But I see that Andreas wants this as well. My 
> problem with such a script would be that it needs too much user 
> interaction and probably it is better to have in the vcs plugins 
> themselves. You have to select branches, versions, merge, resolve, 
> commit, well, good luck with the script. :)

We already worked out how selecting branches would work, versions 
probably needs user input anyway otherwise it would use globalVersion(), 
resourceVersion() and log() I think. Andreas, this is a good question, 
should log() return parsable output for such a script?

>> I think one objective of having a defined interface is to provide the
>> GUI as part of the interface, so that you don't *need* to
>> re-implement the GUI for every back-end.
> 
> Interfaces (in this case) are just like that...interfaces. GUIs are 
> provided by implementation (or as I said by another library). I would 
> like to see this separation kept.

Yes, we agreed there, but the interface is so the GUI can get the data 
it needs, and/or so a generic client can trigger the action consistently.

>> - Allow scripts to use VCS methods
> And this is where I suggest to identify the methods that really make 
> sense to be used from scripts.

for Vic's project, we also want a GUI front-end to be able to call e.g. 
diff() on an arbitrary plug-in. We seem to have raised the question of 
whether diff(), log(), etc should be functions (return parsable output) 
or actions (pop up a UI).

>> ...and this is why log(), globalVersion(), diff(), etc are all things
>> we want in the interface. That way we have *one* GUI using the
>> standardized interface instead of every single back-end reinventing
>> the wheel when it comes to UI's that are common to most/all VCS's.
>>
>> Code reuse = good.
> 
> I'm far from being against code reuse. I'm just on the other side now 
> (compared to the activeProject or activeMainWindow discussion), where I 
> want to have the interfaces as simple as possible by not adding methods 
> that will never be used.

Ok, I can concede that. Unfortunately it is hard to add things later, 
because if we don't add them now, they become optional interfaces and 
you have to check for them to use them. It also means back-ends may be 
slow to adopt the optional interfaces if we create them later.

I think I would rather identify things that are common across VCS's and 
implement them now, but you're welcome to keep trying to change my mind.

>>>> We never really talked about this, but I don't think there should
>>>> be an interface for "special". Individual back-ends can provide
>>>> (outside the defined common interfaces) anything they feel useful.
>>> And how would you access them?
>> The same way you want plugins to provide diff, etc; the back-end adds
>> any additional actions not defined by one of the interfaces it
>> implements. They are only scriptable if you write the script for that
>> specific back-end, and only if said back-end provides them in a
>> script-friendly form. Which is OK.

First, keep in mind that this might be hard to implement if we are using 
the C (or C++, or Qt, or...) libraries for svn because we otherwise 
won't be calling a command line client at all. Second, since this is 
only usable if a plug-in or script knows what back-end it is using, then 
I don't see the problem calling non-standard interfaces directly. And of 
course, third, a back-end that wants can always choose to implement 
command().

-- 
Matthew
Current geek index: 62%