[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r31639 - branches/issue-3000/www

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Thu, 12 Jun 2008 15:35:27 +0100

On Thu, 2008-06-12 at 16:00 +0200, "Andrés G. Aragoneses" wrote:
> Julian Foad wrote:
> > On Thu, 2008-06-12 at 10:40 +0200, "Andrés G. Aragoneses" wrote:
> >> Karl Fogel wrote:
> > [...]
> >>> I'm not sure it makes sense for us to link to every IDE that has
> >>> Subversion support, since huge numbers of them do these days. Instead,
> > [...]
> >
> >> I am not going to argue about this: you have the policies that you want.
> >> But the only thing I would say is: if you don't include MonoDevelop,
> >> please drop also NetBeans, JDeveloper, etc. (just for consistency).
> >
> > You are right, of course, Andrés. Thank you for saying it politely. This
> > decision was bound to come up sooner or later as support for Subversion
> > becomes more widespread, and it just happened to come up now.
> >
> > I have removed those, and one called "Eric", in r31710. The JDeveloper
> > entry did contain a link named "Subversion plugin" but the linked page
> > didn't mention it, so it's not clear what its status is. If there still
> > is a separate plug-in it would be perfectly fine for somebody to
> > reinstate a link to it. (The entry was worded too much like an advert
> > for me to have much sympathy with it :-) .)
> >
> > I have also split up the section (in r31711) into four smaller
> > categories to make it easier to find the links one is interested in.
> Thanks for your answer Julian
> One last thing to discuss: it seems not clear yet for me, upon your and
> Karl's statements, the policy about the inclusion, given that they are a
> bit contradictory: Karl argues about not accepting programs that have
> SVN support (we could define them as anyone who calls svn client API,
> right?) but you seem more focused on having just a "module" for a
> program which is a client.

No, the point is not whether a program calls the API nor whether it is a
"module". The point is whether a user needs our help to find the

Here's what Karl said:
> I'm not sure it makes sense for us to link to every IDE that has
> Subversion support, since huge numbers of them do these days.
> Instead,
> we should link to Subversion-specific clients that a user might not
> otherwise have as part of their development environment.

And here's a note that I wrote in "links.html" in r31711 at the top of
the new "IDE plug-ins" section
> Many Integrated Development Environments support Subversion either
> natively or through a provided plug-in. This section aims to list IDE
> plug-ins that are not provided with the IDE.

Does that help to answer your question?

We _could_ also have a section that lists IDEs (and other software) that
have support for Subversion and says how that support is provided: built
in, through a plug-in module that is provided with the program, and/or
through plug-in modules that are available from separate sources. We
don't currently have a list like this, but if someone would like to
write one I wouldn't mind.

> Regarding your opinion, and not Karl's, MonoDevelop could also be
> included because:
> - It's based on add-ins (more or less the same as plugins).
> - It has a VersionControl add-in [1].
> - It has a Subversion add-in [2], which depends on the former.

I haven't looked closely, but it appears to me that the plug-in is
included with the IDE and is therefore not something that a user would
need to go looking for. Like Karl said about meals and aeroplanes, a
user is not likely to want a whole new IDE just to get Subversion
support, and if they already have the IDE then they don't need our help
in finding the Subversion support in it.

I hope that makes sense.

- Julian

To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-06-12 16:35:52 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.