Hi Eugene, Mark,
About my mistake on the two Subclipses:
Here are my reasons:
While I've seen many requests being shooed away on Subclipse because (1) Subversion doesn't implement it, or (2) CVS doesn't have
it, or (3) it's too difficult to be done or a combination of these, when the same requests are presented to Subclipse we get a
promise of implementation in about 1 week (not the delivery, but the answer : ) the delivery may take some more time, of course).
Subversive doesn't care if Subversion doesn't provide an API for this or that. They'll work their arses to workaround Subversion
limitations in prol of the end user. I have to say that this attitude pleases me more than the one I get from Subclipse.
The second Subclipse should read Subversive. "(...) when the same requests are presented to _Subversive_ (...)".
About:
Just to be clear, when I said it was meaningless, I meant that in the sense that it does not mean our proposal cannot go forward as
well. We had the opportunity to go to the next level back in November. I did not feel I could do it because I knew I was going to
change jobs and I had no way to know if I would land at a job where I could still work on Subclipse. I did not want get the project
approved and then quit the project a week later. None of the other team members had the time available where they felt they could
take the leadership rol, so we decided to hold off on our creation review. I am now working at CollabNet, so this is no longer an
issue. Eclipse has been clear to us that both projects can exist at this stage, it is much later in the process when we would need
to narrow this to one or the other, or combine.
Thanks for making that clear, Mark. Before, It did sound like an attempt to discredit the competition.
What I've been observing in the past few months in Subclipse and Subversive is that Subclipse's proposal is too tied to Subversion
itself
First off, I always want Subclipse to be tied to Subversion. Second, I think your perceptions are outdated. Subversive has been
clear that they are moving themselves towards JavaHL because of the licensing issues. That means they will be faced with the same
issues we have. Of course, they will have the advantage that we have been fixing the issues in Subversion.
I don't think my perceptions are outdated. I have been using Subversive since the second time I've heard you say "that's how CVS
does" or "there's no API support on Subversive to that". I don't think that moving to JavaHL is going to make them give up on their
attempt to workaround Subversion's limitations. The "svn:externals version freeze on tag" issue is the latest example of that, and
it's not 3 weeks old.
while Subversive seems to be really interested in making the Subversion experience in Eclipse hassle-free.
And we want the experience to be full of hassle? This is just marketing BS.
It may be better for Subclipse if you show some more interest on understanding other people's perspectives. Of course this is
all volunteer work (or has been until now) and you're free to do whatever you want with your project. But if your interest is seeing
more people happy with it, hearing people would help.
I'm not affiliated to Subversive or Polarion in any way, I'm just a happy user. And my happiness is explained below:
Here are my reasons:
While I've seen many requests being shooed away on Subclipse because (1) Subversion doesn't implement it, or (2) CVS doesn't have
it, or (3) it's too difficult to be done or a combination of these, when the same requests are presented to Subclipse we get a
promise of implementation in about 1 week (not the delivery, but the answer : ) the delivery may take some more time, of course).
Subversive doesn't care if Subversion doesn't provide an API for this or that. They'll work their arses to workaround Subversion
limitations in prol of the end user. I have to say that this attitude pleases me more than the one I get from Subclipse.
My impression is that we are way more responsive to them. Maybe I am living in a dream land. I monitor their forums, I do not see
questions getting answered very well. As Eugene said, we are largely a volunteer project. Resources come and go. In the end, if
we are not meeting your needs and they are, then you should be using their product. I just wouldn't recommend you make your decision
based on promises as opposed to what is available to use.\
Their users list is not very busy and nobody can beat you on reply speed.
But in the case when a new feature is requested, being the fastest to say "I won't do it" (and worse, sometimes I saw "I won't
accept a patch for it") doesn't help at all.
Their responsiveness comes when an issue is filled through their subversive-bugs list. I had quite a few filled and got
something that felt like a personal treatment. Some were delivered in a week. Every time they showed interest in understanding the
problem and my needs, proposing workarounds while the fix wasn't available.
To me, that's the dream land. And yet, it's real.
It's not because I'm currently using Subversive that I don't care anymore about Subclipse. Being in this list and bothering to
write what I'm writting should prove that. I think that having more than one option is very healthy, and it may happen that when we
get to need something very important, Subclipse will implement it and Subversive won't, although given the history of both that
sounds a bit unlikely.
I just wish that Subclipse would show a little more care than it currently is. I'm sure that everyone would profit from that.
Best regards,
Felipe
- application/x-pkcs7-signature attachment: smime.p7s
Received on Mon Mar 12 14:57:56 2007