Re: [gedit-list] Project management, subversion/SCM integration

[Jesse van den Kieboom <jesse icecrew nl>]

Op maandag 24-11-2008 om 10:48 uur [tijdzone -0500], schreef Vic Fryzel:
> On Mon, Nov 24, 2008 at 9:56 AM, Jesse van den Kieboom
> <jesse icecrew nl> wrote:
>         What I'd like to see is a clear design from the start, making
>         it easy to
>         support multiple SCM's in the same plugin, not in different
>         ones. I
>         therefore opt to combine our forces here and first put up a
>         requirements/design document.
> 
> Jesse,
> 
> I disagree that a general, abstract mechanism would be best for this,
> in the sense that it could be a limiting factor when implementing the
> more specific features of a SCM.  I'm more than comfortable with
> creating an SRS and design document, however I don't think that
> abstractability is a requirement we should keep in this case.  I think
> instead we could come up with common components for the plugins to
> use, like a diff viewer, or extending the file browser plugin, which
> has already begun.

I'll have to fully disagree with this. There is no need for all kinds of
different plugins that basicly do the same stuff, but with different
underlying systems. Abstracting certain common functionality does not
mean that specific backend systems cannot provide additional
functionality on top of the common ones.

> 
> I'm basing this on a guess that you had envisioned a command pattern
> or template method pattern application for all of the SCM plugins.
> 
> Do you agree that combining them all into the same plugin might not be
> in the best interests of users?  For instance, to install the plugin,
> one may be required to install libs for every SCM supported.  I
> started this thread asking the chances of getting SCM support merged
> into trunk, without a plugin, and Matěj asked why not a plugin?  I
> think he was right, it might have bloated gedit for those who didn't
> want the bloat.  Doesn't the same thing apply in this case?

I don't agree here. I'm not suggesting that we would distribute all
systems with the plugin, but the plugin should serve as a common
framework. You can download/install additional backends which are
plugged in to this plugin. This ensures a consistent
look/feel/integration and maintainability. Of course this kind of
functionality will not be put in the gedit core. gedit is first and
foremost a simple text editor. There is no need nor use for such SCM
integration in the core. This is exactly what the plugin system is for.

> I also don't think the plugins should be maintained under a common
> project unless they're going to be shipped with gedit, this is just a
> personal preference.  I'm comfortable maintaining gedit-svn, for
> instance, and keeping it up to date with gedit trunk.

Why not, all these plugins will diverge, will have a different look and
feel, different functionality and a lot of things have to be separately
maintained, even though there is much common ground. And yes, I think
this plugin, when properly developed, should go into the gedit-plugins
package.

> Thanks.
> 
> 
> -- 
> Vic Fryzel (vic dot fryzel at gmail dot com)
-- 
Jesse van den Kieboom

Personal: http://www.icecrew.nl
Professional: http://www.novowork.com