[RFC] Workingstyle of different VCS systems

[Andreas Pakulat]

On 05.04.07 18:10:44, Matthew Woehlke wrote:
> Andreas Pakulat wrote:
> >> Or is KDevelop4 dropping KTextEditor support?
> > 
> > No, at least not as long as kate-devs still call it KTextEditor ;)
> 
> :-)
> 
> ...but the question was, isn't the point of KTextEditor to allow other 
> back-ends? I admit I'm not very familiar with the module ownership here, 
> but, while KATE obviously has to support such an interface extension, 
> does KATE also own the interface definition, or would that be a topic 
> for k-c-d?

The KTextEditor interface is part of the katepart in kdelibs. It is
however maintained by the kate developers, which hang out on
kwrite-devel. Yes its basically possible to have other editors with the
same interface, and in fact there is the yzis editor which tries to
bring a vim-like editor under the KTextEditor interface. 

> This brings up the interesting point, however, that my personal 
> inclination would be to label the menu item "copy/branch"... because the 
> way I think about it there really is no "copy" in VCS because a "copy" 
> *is" a "branch". :-)
> > Anyway, as I said above, both branching and tagging should be left to
> > the vcs plugin. I don't see the need for this to be in the common VCS
> > interface.
> 
> Hmm, there I disagree, branching is pretty fundamental, I would prefer 
> to see that in the common interface. Wasn't the original post 
> suggestions for the common interface, or did I mis-read somewhere?

No you did not mis-read. However I think copy and branch are not the
same thing (except maybe in svn), i.e. I can copy filea.cpp to fileb.cpp
(or rather do copy filea.cpp ../otherdir/fileb.cpp, for whatever
reasons). While a branch really is a copy of a whole project for a
specific matter (be it a feature branch or a maintenance branch). So if
we want to support that via our VCS interface we'd have to have branch
too.

> One way to have shared optional interfaces might be to do something like 
> standard actions, that is something using the plug-in can query if it 
> supports a standard action, and back ends would add standard actions 
> that they support.

Uhm, well I think thats not really needed. A plugin can provide its own
context menu and I still plan to have a special() member function
(optional of course) that allows to execute an arbitrary VCS command.
This would look at the command and arguments and if it finds something
wrong with them it would just be a no-op.

The thing is especially with the arguments for each action, we'd pretty
much end up with something similar to the svn ioslave in KDE3. And I
don't like that interface (you add an int as command and then an
apropriate number of arguments depending on the command). 

Also optional functions in an extension interface are possible too, just
add an empty body to it in the interface (yes the class is not
completely abstract anymore then). Or use multiple interfaces:

IVersionControl for basic stuff
IBranchVCS for branch/tag/...
ICleanupVCS for cleanup/sync
IWhatever for whatever ;)

Now that I think about it, this is the best way and actually exactly
what the extension interfaces can help with. A vcs plugin must implement
IVersionControl, and can additionally implement any of the others. It
provides the information which interfaces it implements already.

Andreas

-- 
Don't read everything you believe.