VCS Interfaces, round 3

Andreas Pakulat apaku at gmx.de
Fri May 4 15:23:26 UTC 2007


On 04.05.07 10:17:40, dukju ahn wrote:
> 2007/5/4, Andreas Pakulat <apaku at gmx.de>:
> > On 04.05.07 09:00:40, dukju ahn wrote:
> > > Detailed operations of plugins should be reserved to each plugin,
> > > to keep the maximal flexibility each Vcs systems offer.
> >
> > I disagree. Commit() can easily commit everything within that directory
> > as it will also take a commit message. If I call
> > commit("/home/andreas/KDE-work/4.0/kdevelop/buildtools/managers/qmake","Applied
> > Patch to make QMake Manager follow users mind") in a script thats what I
> > want, commit everything in that dir. commit() and log() shouldn't open a
> > GUI at all, thats what showLog() and showCommit() are for.
> 
> I understand. But then there is no way to specify every detailed options
> each Vcs's provide.

Yes, and this is a good thing. The VCS interface is not about what SVN
provides and can do, but what is a common denominator for multiple VCS
systems. You can easily setup a ISubversion interface that your plugin
provides with more customizable log() functions.

> For example, subversion takes 2~3 extra flags that are very useful
> (such as limit the number of log,

That will be included in the interface as its really useful.

> don't show before branching point..etc).

The interface will default to follow branches.

> These flags are unique in subversion but other
> Vcs's such as CVS/perforce may have their own unique options.
> Then How can we specify these options? Do we just discard them?

See above, the plugins can easily provide a I<VCSName> of their own if
they want. Then a script that knows it works with Perforce it can ask
the plugin for this interface. However scripts that don't care for the
underlying VCS will still be able to work with the IBasicVersionControl.

Andreas

-- 
There is a fly on your nose.




More information about the KDevelop-devel mailing list