[RFC] Workingstyle of different VCS systems

[Andras Mantia]

On Friday 13 April 2007, Matthew Woehlke wrote:
> > 1) a third party plugin wants to do some VCS operation
>
> I guess writing a generic VCS UI would fall into this category?

No, that is not a third party plugin in this sense. 

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

> > 2) you make a script to do more VCS operations in automatic ways
>
> 3) to provide consistency of interface
> 4) to enable sharing of translations

See my suggestion about the library.

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

> Ah, well you could do that too. Can you edit a non-locked file? 

I don't remember exactly, but probably you can. It was too long ago.

> > Separate GUI? It will be provided by the plugin.
>
> 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.

> > Do we want such a GUI? I mean, will the plugins only do backend
> > stuff and not plug their actions into the user interface and
> > instead we have another plugin for the GUI? It doesn't really make
> > sense because of the differences between the VCS variants.
>
> Why not? :-) One thing I get from this is that different VCS's
> /aren't/ that different, or at least can be easily made to seem
> similar enough that you can do exactly this.

I was asking because it was not clear what are the purpose of the whole 
discussion.

> We're not talking about only scripts, we're also talking about
> KDevelop. Why should I not be able to click on a file I am working on
> and say 'how is my working copy different from the latest repo
> copy?'. Would you prefer to have to leave KDevelop and go to some
> other application (or a command line) to do this?

Andreas already answered this.

> Which, that it's too bad it's so hard to preserve history on CVS?
> It's just stating a fact. ;-)

The fact is that the users should know what will happen in this case, 
otherwise they might assume the history is kept, but it isn't.

> Ok, that's fine, I don't see why copy() can't produces a warning. :-)

Good. :)

> Ok, I think I can clarify. The point of an interface is to:
> - Improve consistency by...
>    - Standardizing the presentation of VCS actions
>    - Allow sharing translations (which makes translators lives
> easier) - Using common GUI's

This can be in the library I proposed.

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

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

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

I don't understand this. Do you want to dig up the actions from the 
back-ends actionCollection (if writing a plugin) and call them, or use 
dbus from scripts to call an action by its name? Why would this better 
than a "special" method which you can use to send a command (and 
arguments) to a back-end?

> Hmm... ok, you're right about open AFAIK. You are overloading the
> 'save' provided by KTE? (Does that work? It catches also ctrl-s, for
> example?) I'm not sure if that is preferable to having KTE emit a
> signal or not, the latter sure seems to be safer. (aegis also needs
> to do a 'save as' instead of a 'save', so I guess Quanta is not
> alone...)

See my other mail why it is not a must to provide the onsave by the 
ktexteditor part and how this can be implemented. There are other 
actions that might need similar "redirections", and a similar technique 
can be used to get back shortcuts for the platform. ;)

Andras
-- 
Quanta Plus developer - http://quanta.kdewebdev.org
K Desktop Environment - http://www.kde.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20070413/3cb74e02/attachment.sig>