[RFC] Workingstyle of different VCS systems

[Matt Rogers]

On Thursday 05 April 2007 20:21, Andreas Pakulat wrote:
> 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.
>

No, KTextEditor is only implemented by katepart in kdelibs. It's defined in 
kdelibs/interfaces/texteditors.


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

copy and branch should be treated as separate operations. even though several 
SCM systems make them basically the same operations, we shouldn't treat them 
as such.

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

Sounds good to me too.
-- 
Matt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20070405/1da6dc2d/attachment.sig>