Home » Eclipse Projects » Subversive » Why I favor Subclipse over Subversive.
| Why I favor Subclipse over Subversive. [message #2626] |
Mon, 31 July 2006 14:47  |
Eclipse User |
|
|
|
Originally posted by: kfogel.google.com
[This is related to both svn proposals, but I would probably have posted
it in eclipse.technology.svn if the newsportal made that group
available...]
I've been reading over the threads about the pros/cons of both the
Subversive and the Subclipse proposals. I understand that the Eclipse
Foundation needs to remain neutral and "above the fray" when it comes
to making judgements about projects, but I hope that policy doesn't go
so far that it precludes the Foundation from taking relevant information
into account -- including information about the people & communities
behind the proposals.
The developers of Subclipse have always maintained an extremely close
working relationship with the core Subversion development team. They
contribute bugfixes back, they help us tune APIs to be more useful for
themselves and other plugin authors -- there is even some direct
crossover in the fact that some people are committers in both projects.
We know who they are; they know who we are. They "get" open source,
and they have proven that their community is here for the long haul.
Compare that with the Subversive proposal: Polarion has never been
involved with Subversion development or API design -- we simply don't
see them on the development lists at all. They currently control the
domain subversion.com, and have put there a site that lies somewhere
between misleading and deceptive: reading the copy on those pages,
you could come away with the impression that Subversion is somehow
a project of Polarion. (The real Subversion home site is listed
last in their list of "useful links"!) Furthermore, although there
is a lot of talk about "community" on those pages, there is no actual
community there. Every link to a forum or an issue tracker is offsite
(some of them are to Subversion's real home site, subversion.tigris.org,
for which I suppose we should be grateful).
To be perfectly clear: I have no problem with Polarion making money from
Subversion. The problem is that they seem to be allergic to actually
working with an open source developer community, and that they are
willing to blur proper attribution to their own advantage.
The JavaSVN library's authors are separate from Polarion, and should
not be included in the above indictment. However, there are technical
reasons, as well as (at the moment) license reasons, to prefer the
JavaHL library instead of the pure-Java JavaSVN library: the former
will have a much easier time keeping up with the Subversion APIs. As
Mark Phippard has already pointed out, CVS never had real APIs, so
looking to the CVS plugin's design for guidance would be comparing
apples to oranges.
In summary:
It would be great if we could evaluate the two Eclipse plugin
proposals solely on the technical merits as expressed in the proposal
documents. But "technical merit" must also include the maintainers'
committment to open source processes, their ability to bring others
into their community, and to work with the Subversion development
community. On these points, the Subclipse folks win hands down, and
this gives Subclipse much better prospects for long-term quality, IMHO.
I hope everyone involved in this decision will take that into account.
Thank you
-Karl Fogel, Subversion committer
|
|
|
| Re: Why I favor Subclipse over Subversive. [message #2655 is a reply to message #2626] |
Mon, 31 July 2006 14:59  |
| Eclipse User |
|
|
|
Originally posted by: markp.softlanding.com
Karl Fogel wrote:
> [This is related to both svn proposals, but I would probably have
> posted it in eclipse.technology.svn if the newsportal made that group
> available...]
>
> I've been reading over the threads about the pros/cons of both the
> Subversive and the Subclipse proposals. I understand that the Eclipse
> Foundation needs to remain neutral and "above the fray" when it comes
> to making judgements about projects, but I hope that policy doesn't go
> so far that it precludes the Foundation from taking relevant
> information into account -- including information about the people &
> communities behind the proposals.
>
> The developers of Subclipse have always maintained an extremely close
> working relationship with the core Subversion development team. They
> contribute bugfixes back, they help us tune APIs to be more useful for
> themselves and other plugin authors -- there is even some direct
> crossover in the fact that some people are committers in both
> projects. We know who they are; they know who we are. They "get"
> open source, and they have proven that their community is here for
> the long haul.
>
> Compare that with the Subversive proposal: Polarion has never been
> involved with Subversion development or API design -- we simply don't
> see them on the development lists at all. They currently control the
> domain subversion.com, and have put there a site that lies somewhere
> between misleading and deceptive: reading the copy on those pages,
> you could come away with the impression that Subversion is somehow
> a project of Polarion. (The real Subversion home site is listed
> last in their list of "useful links"!) Furthermore, although there
> is a lot of talk about "community" on those pages, there is no actual
> community there. Every link to a forum or an issue tracker is offsite
> (some of them are to Subversion's real home site,
> subversion.tigris.org, for which I suppose we should be grateful).
>
> To be perfectly clear: I have no problem with Polarion making money
> from Subversion. The problem is that they seem to be allergic to
> actually working with an open source developer community, and that
> they are willing to blur proper attribution to their own advantage.
>
> The JavaSVN library's authors are separate from Polarion, and should
> not be included in the above indictment. However, there are technical
> reasons, as well as (at the moment) license reasons, to prefer the
> JavaHL library instead of the pure-Java JavaSVN library: the former
> will have a much easier time keeping up with the Subversion APIs. As
> Mark Phippard has already pointed out, CVS never had real APIs, so
> looking to the CVS plugin's design for guidance would be comparing
> apples to oranges.
>
> In summary:
>
> It would be great if we could evaluate the two Eclipse plugin
> proposals solely on the technical merits as expressed in the proposal
> documents. But "technical merit" must also include the maintainers'
> committment to open source processes, their ability to bring others
> into their community, and to work with the Subversion development
> community. On these points, the Subclipse folks win hands down, and
> this gives Subclipse much better prospects for long-term quality,
> IMHO. I hope everyone involved in this decision will take that into
> account.
>
> Thank you
> -Karl Fogel, Subversion committer
Thanks Karl!
I am mainly just replying so that I can get it cross-posted over to our
newsgroup.
Mark
|
|
| |
| Re: Why I favor Subclipse over Subversive. [message #3746 is a reply to message #2684] |
Mon, 31 July 2006 16:48 |
| Eclipse User |
|
|
|
Originally posted by: markp.softlanding.com
Konstantin Scheglov wrote:
> Karl Fogel wrote:
>
> > The developers of Subclipse have always maintained an extremely
> > close working relationship with the core Subversion development
> > team. They contribute bugfixes back, they help us tune APIs to be
> > more useful for themselves and other plugin authors -- there is
> > even some direct crossover in the fact that some people are
> > committers in both projects. We know who they are; they know who
> > we are. They "get" open source, and they have proven that their
> > community is here for the long haul.
>
> I, as user, don't care about "community" or how anybody "got" open
> source. I just see that one project has long history of slow
> development with bugs and missing features. And I see also second
> project that was useful for me starting from first version. Do you
> want good looking project that is nice for community, etc? I just
> want use SVN and preffer fast moving projects.
If you want the project to "last" and stay current with Subversion
(which unlike CVS does not stand still) then you should care.
Here are the changelogs for Subclipse, by what standards is this "slow
development"?
http://subclipse.tigris.org/subclipse/pre_1.0.html
http://subclipse.tigris.org/subclipse/changes.html
http://subclipse.tigris.org/subclipse_1.2.x/changes.html
In my opinion, Subclipse is far more stable and has many more features
than Subversive at this time. Subversive has some nice features, I can
understand why someone might prefer it, but your comments about
Subclipse are just untrue.
Mark
|
|
| |
| Re: Why I favor Subclipse over Subversive. [message #3761 is a reply to message #3746] |
Tue, 01 August 2006 04:17 |
| Eclipse User |
|
|
|
Mark Phippard wrote:
> If you want the project to "last" and stay current with Subversion
> (which unlike CVS does not stand still) then you should care.
In any case new features require coding in Java to show them in Eclipse.
> Here are the changelogs for Subclipse, by what standards is this "slow
> development"?
>
> http://subclipse.tigris.org/subclipse/pre_1.0.html
> http://subclipse.tigris.org/subclipse/changes.html
> http://subclipse.tigris.org/subclipse_1.2.x/changes.html
>
> In my opinion, Subclipse is far more stable and has many more features
> than Subversive at this time. Subversive has some nice features, I can
> understand why someone might prefer it, but your comments about
> Subclipse are just untrue.
I've tried to switch to SVN several times in last two years and
several times tried Subclipse and other SVN plugins for Eclipse. And
always I saw that SVN support is not so good as support for CVS. Last
time (at the end of 2005 or beginning of 2006) I've installed Subclipse
and in general it was usable, but slow and buggy (I don't remember
exactly, but I have had problems with moving/renaming files, commits for
several projects, some delayed operations and errors). And all this
after several years of Subclipse development. I call this slow development.
After couple weeks I've installed Subversive and found that it works
just as I want. Fast, nice looking, no bugs in features that I use and
all what I need is supported. Just in first version of Subversive that
I've installed. And now I should return back to Subclipse? No, thank you.
--
SY, Konstantin.
Advanced Eclipse SWT Designer (http://www.swt-designer.com)
|
|
|
| Re: Why I favor Subclipse over Subversive. [message #3769 is a reply to message #3754] |
Tue, 01 August 2006 09:00 |
| Eclipse User |
|
|
|
Originally posted by: markp.softlanding.com
Phillip Baird wrote:
> From a usability point of view Subclipse had some ugly things
> happening in the UI. e.g. I could see what needed to be committed in
> the Synchronize view but when I went to commit I had to reselect
> everything I wanted to commit. At the time it honestly felt like
> TortoiseSVN had been shoe-horned into Eclipse.
The commit dialog shows unversioned files. These are not selected by
default, although there is a preference to change this. It used to be
the opposite but we had a lot of people beg us to make them unselected
by default so we changed it and made it a preference. If the Team ->
Add option has been taken then the files are selected and of course
modified and deleted files are selected.
> At the time, from my "users" point of view, Subversive was head and
> shoulders ahead of Subclipse. Maybe that has now changed, but in the
> discussions I've read so far I haven't heard any convincing argument
> why I'd want to change.
I am happy that Subversive works well for you. Unlike the people that
insist on attacking Subclipse and claim it does not work, I have never
made that claim about Subversive. It just comes down to what features
are important to you. Subclipse has more compare features, supports
things like quick diff and live annotations, has support for all
Subversion commands and I think has less bugs overall. Obviously every
release of Subversive closes that gap, but for me it was not until the
final release candidate that I could get merge to work at all and I
have to do that on a daily basis. I also did not like not having a
console view, which was recently added. The other problem I have is
the lack of documentation, so there are certain features where I do not
know what the intended functionality is supposed to be so it is hard to
know if it does not work yet, or I just do not understand what it is
supposed to do.
> From a user's perspective what can Subclipse do for me that
> Subversive cannot? Why should I favor Subclipse over Subversive?
These proposals are not really about Subclipse versus Subversive, it is
about creating a new project that is part of Eclipse. Hopefully that
project will take on the best features from both projects and we will
work together to make it happen. I have made the arguments as to why I
think Subclipse is the better starting point in our proposal.
Mark
|
|
|
| Re: Why I favor Subclipse over Subversive. [message #3776 is a reply to message #3761] |
Tue, 01 August 2006 09:08 |
| Eclipse User |
|
|
|
Originally posted by: markp.softlanding.com
Konstantin Scheglov wrote:
> I've tried to switch to SVN several times in last two years and
> several times tried Subclipse and other SVN plugins for Eclipse. And
> always I saw that SVN support is not so good as support for CVS. Last
> time (at the end of 2005 or beginning of 2006) I've installed
> Subclipse and in general it was usable, but slow and buggy (I don't
> remember exactly, but I have had problems with moving/renaming files,
> commits for several projects, some delayed operations and errors).
> And all this after several years of Subclipse development. I call
> this slow development.
Moving/renaming is still an issue sometimes. We use Subversion API and
it has limitations, such as not letting you move/rename a file more
than once without a commit. Our team recently removed this limitation
in Subversion and it has been committed to the Subversion trunk and
will be part of the 1.5 release. The JavaSVN API used by Subversion
enhanced this on their own which is what Subversive does not have the
issue.
Subclipse has supported commit of several projects in one action for at
least a year.
> After couple weeks I've installed Subversive and found that it works
> just as I want. Fast, nice looking, no bugs in features that I use
> and all what I need is supported. Just in first version of Subversive
> that I've installed. And now I should return back to Subclipse? No,
> thank you.
I am not asking anyone to switch to Subclipse. These forums are to
discuss a new project to bring Subversion support to Eclipse
Foundation. You can use whatever you want today, and even after this
new project is created. I think that there are reasons why it makes
sense to use Subclipse as the starting point for this new project but
hopefully our teams will find a way to bring the best features of both
projects together into one new project.
Mark
|
|
|
| Re: Why I favor Subclipse over Subversive. [message #3783 is a reply to message #3776] |
Tue, 01 August 2006 09:39 |
| Eclipse User |
|
|
|
Mark Phippard wrote:
> Moving/renaming is still an issue sometimes. We use Subversion API and
> it has limitations, such as not letting you move/rename a file more
> than once without a commit. Our team recently removed this limitation
> in Subversion and it has been committed to the Subversion trunk and
> will be part of the 1.5 release. The JavaSVN API used by Subversion
> enhanced this on their own which is what Subversive does not have the
> issue.
Well, now I know this.
I see that this was objective problem for Subclipse, but why such
important bug was fixed only now? Main reason why I personally switched
to SVN is keeping history after rename/move and single commit operation
for all projects in repository. And Subclipse did not support these two
main features. :-( Annotations, history, console - nice features, but
they are useless if core functions works bad. Ah, one more problem why I
stayed with CVS long time - synchronize. Again, it was in Subversive
from beginning and was not in Subclipse long time.
> Subclipse has supported commit of several projects in one action for at
> least a year.
Last time when I tried it really allowed me to do commit for several
projects, but asked comment for each project and did separate commit for
each project. At least this is how it looked from user perspective -
just decoration for several sub-actions.
>> After couple weeks I've installed Subversive and found that it works
>> just as I want. Fast, nice looking, no bugs in features that I use
>> and all what I need is supported. Just in first version of Subversive
>> that I've installed. And now I should return back to Subclipse? No,
>> thank you.
>
> I am not asking anyone to switch to Subclipse. These forums are to
> discuss a new project to bring Subversion support to Eclipse
> Foundation. You can use whatever you want today, and even after this
> new project is created. I think that there are reasons why it makes
> sense to use Subclipse as the starting point for this new project but
> hopefully our teams will find a way to bring the best features of both
> projects together into one new project.
Problem is that if Subclipse will be base for standard SVN support
for Eclipse, I afraid that it will again developed slow, with
concentration on nice looking, but not so important features.
--
SY, Konstantin.
Advanced Eclipse SWT Designer (http://www.swt-designer.com)
|
|
| | | | | | |
| Re: Why I favor Subclipse over Subversive. [message #3863 is a reply to message #3783] |
Fri, 04 August 2006 01:58 |
| Eclipse User |
|
|
|
Konstantin Scheglov wrote:
> Mark Phippard wrote:
>
>> Moving/renaming is still an issue sometimes. We use Subversion API and
>> it has limitations, such as not letting you move/rename a file more
>> than once without a commit. Our team recently removed this limitation
>> in Subversion and it has been committed to the Subversion trunk and
>> will be part of the 1.5 release. The JavaSVN API used by Subversion
>> enhanced this on their own which is what Subversive does not have the
>> issue.
>
> Well, now I know this.
>
> I see that this was objective problem for Subclipse, but why such
> important bug was fixed only now? Main reason why I personally switched
> to SVN is keeping history after rename/move and single commit operation
> for all projects in repository. And Subclipse did not support these two
> main features.
For the purposes of the "SVN Team Provider" proposal, the important
thing about this for me, as a user, is that the Subclipse team helped
provide this enhancement to Subversion itself, not just their tool.
That is, when Subversion 1.5 is released, I will be able to use this
feature from any client that uses the native libraries, whether it is
the command line, an IDE plugin, something like TortoiseSVN, etc. (And I
don't think this one would require any recoding in Java, since the APIs
are backwards compatible.)
I have some concerns about a pure Java solution that I am not sure are
addressed by the Subversive proposal. Mostly it's just whether such an
effort will be able to keep up with subversion itself. For example,
subversion 1.4 is making changes to the working copy format. I'm sure
tmate.org is aware of this and working on it, but there is no way to
predict the level of effort that will be required to maintain
compatibility with changes like these in the future, and whether playing
catch up would start affecting the release of new features.
Also, there are some things that I can't do with JavaSVN right now that
the native libs can, like GSSAPI Single-Sign-On using OS credentials.
(Java 1.6 is supposed to have support for this...)
:-( Annotations, history, console - nice features, but
> they are useless if core functions works bad. Ah, one more problem why I
> stayed with CVS long time - synchronize. Again, it was in Subversive
> from beginning and was not in Subclipse long time.
>
To some extent, comparing subversion to CVS is fair, since svn is
getting pretty popular as the de facto replacement for CVS. However, at
some point that comparison is just going to be unproductive because I
don't expect any SCM system to be a drop in replacement for another
(even the one it's supposed to be a replacement for).
Admittedly, I had never used the CVS plugin before using Subclipse, so I
never missed synchronize (all command line for me), but I had work with
a project that was still using CVS a few months ago, and it made me
realize why it's almost painful to work with CVS without it (a credit to
the CVS Team provider team). The only problem seems to be an
unwillingness from some users to learn anything about how a new SCM they
have chosen actually works (again, an issue only because of the
replacement mentality of using svn instead of CVS, or maybe only a
problem because they come to me to ask about it). That said, I hope
both "feature set compared with the CVS plugin" and "feature set of svn
plugin x v. y" don't factor as highly into the evaluation of the
proposals as other aspects.
All that said, I support the proposal from the Subclipse team because I
think they show a willingness, and have a record of, wanting to improve
both Eclipse and subversion, and have had a very open process, including
the acceptance of complete patches, since I have been using it (for over
a year and half). (Of course, I speak only for myself, a user of Subclipse.)
-Tony
|
|
|
| Re: Why I favor Subclipse over Subversive. [message #4158 is a reply to message #3863] |
Tue, 08 August 2006 05:25 |
| Eclipse User |
|
|
|
Originally posted by: michal.dobisek.polarion.com
"Antony Saba" <awsaba@sandia.gov> wrote:
> All that said, I support the proposal from the Subclipse team because I
> think they show a willingness, and have a record of, wanting to improve
> both Eclipse and subversion, and have had a very open process, including
> the acceptance of complete patches, since I have been using it (for over a
> year and half). (Of course, I speak only for myself, a user of Subclipse.)
Well, for completeness it's fair to mention, that Subversive works with
patches and contributions from community as well. During the 5 months the
project is out public, we have some 6 patches from 3 contributors, which
seems not bad at all.
Michal
|
|
|
| Re: Why I favor Subclipse over Subversive. [message #4436 is a reply to message #2655] |
Tue, 08 August 2006 10:58 |
| Eclipse User |
|
|
|
Originally posted by: michal.dobisek.polarion.com
Karl Fogel wrote:
>> The developers of Subclipse have always maintained an extremely close
>> working relationship with the core Subversion development team. They
>> contribute bugfixes back, they help us tune APIs to be more useful for
>> themselves and other plugin authors -- there is even some direct
>> crossover in the fact that some people are committers in both
>> projects. We know who they are; they know who we are. They "get"
>> open source, and they have proven that their community is here for
>> the long haul.
>>
>> Compare that with the Subversive proposal: Polarion has never been
>> involved with Subversion development or API design -- we simply don't
This is quite logical - Subclipse is using JavaHL as they way of accessing
Subversion - therefore they did contribute/communicate with it's
development. While Subversive was based on JavaSVN, and thus communicated
with (and also actively supported) JavaSVN development. E.g. the support for
single commit over multiple projects was based on our requests.
>> see them on the development lists at all. They currently control the
>> domain subversion.com, and have put there a site that lies somewhere
>> between misleading and deceptive: reading the copy on those pages,
>> you could come away with the impression that Subversion is somehow
>> a project of Polarion. (The real Subversion home site is listed
>> last in their list of "useful links"!) Furthermore, although there
>> is a lot of talk about "community" on those pages, there is no actual
>> community there. Every link to a forum or an issue tracker is offsite
The fact, that url is different (polarion.org for root, vs.
forums.polarion.org for forums vs. community.polarion.org for
tracker/builds...) does not mean, that it's 'offsite' - all these three were
designed to work together. I don't know, how you call hundreds of forum
users, hundreds of mail list members and tens of code contributors, but we
feel it's OK to call this community.
These were two things, which IMO deserved to be mentioned to keep the
balance.
Cheers,
Michal Dobisek
Polarion
|
|
| |
| Re: Why I favor Subclipse over Subversive. [message #6506 is a reply to message #3863] |
Mon, 13 November 2006 13:04 |
| Eclipse User |
|
|
|
Dear Tony,
Thank you for sharing your opinion. Many things changed during last few
months, so I want to provide an information regarding questions, which you
raised here.
First of all I want to inform you that Subversive library-independent: now
you can select to use JavaHL, standard JavaSVN or extended JavaSVN. This
turn allows us resolving problems with SVN evolution, which you pointed. SVN
1.4 was released near 2 month ago, but JavaSVN authors need some time to
reflect working copy changes, so their release comes after SVN release with
delay of few month (we are waiting release 1.1.0 soon). It can be really a
problem for some users, but now they have different options.
Regarding the process - don't want be self-advocate here, but just few
facts:
Subversive patches list:
http://www.polarion.org/index.php?page=patches&project=s ubversive
Implemented integrations with other projects together with other teams:
Mylar, Buckminster, Project Set
Best regards,
Igor Vinnykov
Subversive Team
"Antony Saba" <awsaba@sandia.gov> ???????/???????? ? ???????? ?????????:
news:eaunlu$dll$1@utils.eclipse.org...
> For the purposes of the "SVN Team Provider" proposal, the important thing
> about this for me, as a user, is that the Subclipse team helped provide
> this enhancement to Subversion itself, not just their tool. That is, when
> Subversion 1.5 is released, I will be able to use this feature from any
> client that uses the native libraries, whether it is the command line, an
> IDE plugin, something like TortoiseSVN, etc. (And I don't think this one
> would require any recoding in Java, since the APIs are backwards
> compatible.)
>
> I have some concerns about a pure Java solution that I am not sure are
> addressed by the Subversive proposal. Mostly it's just whether such an
> effort will be able to keep up with subversion itself. For example,
> subversion 1.4 is making changes to the working copy format. I'm sure
> tmate.org is aware of this and working on it, but there is no way to
> predict the level of effort that will be required to maintain
> compatibility with changes like these in the future, and whether playing
> catch up would start affecting the release of new features.
>
> Also, there are some things that I can't do with JavaSVN right now that
> the native libs can, like GSSAPI Single-Sign-On using OS credentials.
> (Java 1.6 is supposed to have support for this...)
>
> To some extent, comparing subversion to CVS is fair, since svn is getting
> pretty popular as the de facto replacement for CVS. However, at some
> point that comparison is just going to be unproductive because I don't
> expect any SCM system to be a drop in replacement for another (even the
> one it's supposed to be a replacement for).
>
> Admittedly, I had never used the CVS plugin before using Subclipse, so I
> never missed synchronize (all command line for me), but I had work with a
> project that was still using CVS a few months ago, and it made me realize
> why it's almost painful to work with CVS without it (a credit to the CVS
> Team provider team). The only problem seems to be an unwillingness from
> some users to learn anything about how a new SCM they have chosen actually
> works (again, an issue only because of the replacement mentality of using
> svn instead of CVS, or maybe only a problem because they come to me to ask
> about it). That said, I hope both "feature set compared with the CVS
> plugin" and "feature set of svn plugin x v. y" don't factor as highly into
> the evaluation of the proposals as other aspects.
>
> All that said, I support the proposal from the Subclipse team because I
> think they show a willingness, and have a record of, wanting to improve
> both Eclipse and subversion, and have had a very open process, including
> the acceptance of complete patches, since I have been using it (for over a
> year and half). (Of course, I speak only for myself, a user of Subclipse.)
>
> -Tony
|
|
|
Goto Forum:
Current Time: Sun May 11 13:43:39 EDT 2025
Powered by FUDForum. Page generated in 0.04074 seconds |
Home