Home » Eclipse Projects » Subversive » Cooperation Subclipse, Subversive
| Cooperation Subclipse, Subversive [message #4849] |
Tue, 22 August 2006 15:36  |
 Antonin Pokorny
Messages: 1
Registered: July 2009 |
Junior Member |
|
|
Hi Mark and Subclipse team members,
it seems that both proposal and behind staying teams try to reach the same
goal,
i.e. to deliver a high quality Subversion support to Eclipse IDE.
I am coming here with wish to rework current setup into a positive
environment where all the people will invest their efforts into the #1
goal;
svn support finally part of eclipse.
Id like to keep neutral language here and keep focus on the goal, although
I am coming from the Polarion Software company, which is a sponsor of the
Subversive team.
Current situation where both proposals invoke each other to drop their
codebase, switch
to the 'competing' one and contribute, just will not work.
Both proposals contain the same idea to start with codebase of
Subclipse/Subversive.
As both of them solve the same problem in similar environment, there is
quite good
probability, that at least layers like svn client access, core, ui exist
in similar
form in both products.
I propose to start with agreement on APIs of fundamental layers(these APIs
could act
as initial clue) and then analyze seriously codebase of Subclipse and
Subversive and decide
for each component where it should be taken from or whether it should be
re-implemented
combining the strong points of both projects. The method of analysis
should be agreed up-front,
of course.
Besides that, do you see any area/practice where the Subversive team is
better
that the Subclipse team? Of course, except icons :) The Subversive team,
for example,
rates your communication skills and built and working communication
channel with the
JavaHL developers.
Please consider that the Foundation needs us to find a solution how to
cooperate
and that the solution we need is a stable one.
I am looking forward to your reply.
Best regards,
Antonin, Polarion
|
|
|
| Re: Cooperation Subclipse, Subversive [message #4918 is a reply to message #4849] |
Wed, 23 August 2006 14:57  |
Eclipse User |
|
|
|
Originally posted by: markp.softlanding.com
Antonin Pokorny wrote:
> I propose to start with agreement on APIs of fundamental layers(these
> APIs could act as initial clue) and then analyze seriously codebase
> of Subclipse and Subversive and decide for each component where it
> should be taken from or whether it should be re-implemented combining
> the strong points of both projects. The method of analysis should be
> agreed up-front, of course. Besides that, do you see any
> area/practice where the Subversive team is better that the Subclipse
> team? Of course, except icons :) The Subversive team, for example,
> rates your communication skills and built and working communication
> channel with the JavaHL developers.
You should probably cross-post in the future to be sure we see
something like this. Someone had to point this out to me.
I am on board with the spirit of the request, and in time I could
perhaps be convinced that what you are proposing is the right approach.
With the bit of information you have provided, it just sounds too
difficult and time-consuming to be successful. It is not liked we can
lock ourselves in a room together for a couple of weeks and work all of
this out, and it is not well suited for the nature of our team and the
resources we can bring to bear on this proposal.
We would fully welcome you and your organization to our team and our
proposal. You would have just as much right to implement your ideas on
our codebase as we would. Given that these projects are meritocracies
and you potentially have a lot of resources to bring to the project, I
could even see over time that your organization would have a leadership
role in the project.
I think we should start with the Subclipse codebase for a couple of
reasons:
1) It has a lot more "coverage" of Subversion features as well as
Eclipse features (like quick diff, changesets, live annotations etc..)
2) This proposal almost certainly needs to be based on JavaHL and our
code has more experience in that area. Plus it already allows for
JavaSVN as an option.
3) I think most of the people that like your project better, do so
largely because of UI-related issues (and of course there are some that
like our UI better). But a lot of the people that feel strongly about
our proposal do so based on the open source roots of our project and
the code lineage and contributions. We can always take the best of
your UI and replace our UI. We cannot really change the code issue
other than by starting with it.
I would start with our code and then start incoporating the parts of
your UI that you feel the strongest about. I do not think you would
get a lot of resistance to incorporating your features, we would just
want to know what you plan to do and have an opportunity (in some
cases) to work with you to refine it.
You asked what I like about Subversive?
I like your repository connection dialog and that you are able to
collect all of the information needed for a connection in the dialog.
Of course this is a JavaSVN issue. It allows you to do this. JavaHL
currently does not. Brock has looked at the Subversion code and thinks
it possibly could be enhanced in a way that we could do this.
I am not a big icons person, I just do not care one way or another. I
think yours look fine. In our proposal, I have gone with the CVS
approach. We use the same icons (and lack of icons) as CVS.
I think we each have some Synch view features that the other does not
have.
I like your refactoring support. Subclipse has this too, but JavaSVN
added some enhancements that native Subversion does not have and this
lets your support work better for some refactorings. Our team just
recently committed an enhancement to Subversion to fix this and that
will be in the Subversion 1.5 release.
Here are some other comments:
I can appreciate what you are trying to do with interactive merge, but
it does not work and I do not think you will be able to get it to work.
If you can ever get this to work I am sure a lot of people will like
it, but I do not think you will succeed.
Some of your dialogs, like Merge have bad usability. For example, I
cannot just type in revision numbers, and if I select the revisions I
want to merge I do not get the right revisions in the dialog to perform
that merge. So I have to make non-intuitive selections.
People praise you about this idea that you "recognize" the
trunk/branches/tags structure. I just do not get it. Maybe this is
where if you had some documentation that explained your intent it would
help me. But I do not see your feature doing anything at all. It does
nothing to let me just select a branch/tag and then rewrite the proper
URL's. Actually, I really just do not see where it does anything. Our
subclipse:tags feature does a lot more to automate URL management.
I think I like the way you show affected paths in your History view,
but otherwise, I like some of the features in our History view better
(and a lot is the same).
Performance is a mixed bag. In general, for me, Subclipse is
considerably faster. I was scratching my head with a lot of the
comments I saw to the contrary. We think we have discovered and fixed
the reasons for a lot of this. It had to do with usage patterns that a
lot of our developers were not using. Such as building projects with
external tools like Ant and Maven. This was triggering us to do a lot
of unnecessary status refreshing. This seems to have solved the
problems for people that were reporting their problems to us, so
hopefully we are getting close to better performance for everyone.
This reply has gotten so long I am just going to bring it to an end.
If you take nothing else away from this reply, I would just hope that
it is we agree in principal on the need to work together.
Mark
|
|
|
| Re: Cooperation Subclipse, Subversive [message #4986 is a reply to message #4918] |
Thu, 24 August 2006 11:37 |
Brock Janiczak
Messages: 1
Registered: July 2009 |
Junior Member |
|
|
Before we look at our own APIs I think it would be a good idea to first
agree upon a subversion client library. Right now, the choice of
subversion client APIs seems to be the biggest difference between the
two proposals.
If the decision is made to go with JavaHL we will need to come up with a
list of all features it currently lacks and a plan on how to implement
them. For instance, we will need the ability to:
- Provide our own configuration data so the Java defined http proxy
settings can be used (currently possible, but not though JavaHL)
- Create an SSH tunnel from Java and have this used from JavaHL
- Get access to information on how much data has been transmitted for
progress reporting (this is only possible with the SVN protocol at the
moment)
- Cross WC atomic commit
Are there any other major features JavaHL is missing?
If we then further decide to use the svnClientAdapter abstraction we
will need to look at exposing features of JavaHL that are currently
missing, such as the ability to create multiple remote folders in a
single transaction.
cheers,
Brock
Mark Phippard wrote:
> Antonin Pokorny wrote:
>
>> I propose to start with agreement on APIs of fundamental layers(these
>> APIs could act as initial clue) and then analyze seriously codebase
>> of Subclipse and Subversive and decide for each component where it
>> should be taken from or whether it should be re-implemented combining
>> the strong points of both projects. The method of analysis should be
>> agreed up-front, of course. Besides that, do you see any
>> area/practice where the Subversive team is better that the Subclipse
>> team? Of course, except icons :) The Subversive team, for example,
>> rates your communication skills and built and working communication
>> channel with the JavaHL developers.
>
|
|
|
| Re: Cooperation Subclipse, Subversive [message #5258 is a reply to message #4986] |
Mon, 28 August 2006 12:49 |
Igor Vinnykov
Messages: 61
Registered: July 2009 |
Member |
|
|
Hello Brock, Mark,
Yes, right, difference in used library was really a problem, but now
situation have changed. Both projects (and proposals) are generally
different in one aspect - client library. After Subversive 1.0.0 release we
started a work for unification Subversive and making possible to work
through JavaHL library. Such step made Subversive and Subclipse closer to
each other, so it will simplify projects merge. From the other side in scope
of this task we slightly reworked architecture in order to introduce special
interface layers, which can be used by other plugins for integration. We are
going to publish document at the end of this week, which describes interface
layers and integration approaches. We think that this abstraction is a right
candidate for reuse, so it will be a good start point for discussion.
P.S. Note that currently it's not possible to switch between JavaSVN and
JavaHL in distributed Subversive versions, because JavaHL-based version
requires in-depth testing before publishing. But code is available for
investigation in the repository.
Best regards,
Igor Vinnykov
"Brock Janiczak" <brockj@tpg.com.au> ???????/???????? ? ???????? ?????????:
news:44ED8F62.9080508@tpg.com.au...
> Before we look at our own APIs I think it would be a good idea to first
> agree upon a subversion client library. Right now, the choice of
> subversion client APIs seems to be the biggest difference between the two
> proposals.
>
> If the decision is made to go with JavaHL we will need to come up with a
> list of all features it currently lacks and a plan on how to implement
> them. For instance, we will need the ability to:
> - Provide our own configuration data so the Java defined http proxy
> settings can be used (currently possible, but not though JavaHL)
> - Create an SSH tunnel from Java and have this used from JavaHL
> - Get access to information on how much data has been transmitted for
> progress reporting (this is only possible with the SVN protocol at the
> moment)
> - Cross WC atomic commit
>
> Are there any other major features JavaHL is missing?
>
> If we then further decide to use the svnClientAdapter abstraction we will
> need to look at exposing features of JavaHL that are currently missing,
> such as the ability to create multiple remote folders in a single
> transaction.
>
> cheers,
> Brock
|
|
|
| Re: Cooperation Subclipse, Subversive [message #5324 is a reply to message #5258] |
Mon, 28 August 2006 16:40 |
Eugene Kuleshov
Messages: 504
Registered: July 2009 |
Senior Member |
|
|
This is exactly when you could of be more open to community. E.g.
announce your plans before starting working on them...
regards,
Eugene
Igor Vinnykov wrote:
> Hello Brock, Mark,
>
> Yes, right, difference in used library was really a problem, but now
> situation have changed. Both projects (and proposals) are generally
> different in one aspect - client library. After Subversive 1.0.0 release we
> started a work for unification Subversive and making possible to work
> through JavaHL library. Such step made Subversive and Subclipse closer to
> each other, so it will simplify projects merge. From the other side in scope
> of this task we slightly reworked architecture in order to introduce special
> interface layers, which can be used by other plugins for integration. We are
> going to publish document at the end of this week, which describes interface
> layers and integration approaches. We think that this abstraction is a right
> candidate for reuse, so it will be a good start point for discussion.
>
> P.S. Note that currently it's not possible to switch between JavaSVN and
> JavaHL in distributed Subversive versions, because JavaHL-based version
> requires in-depth testing before publishing. But code is available for
> investigation in the repository.
>
> Best regards,
> Igor Vinnykov
>
> "Brock Janiczak" <brockj@tpg.com.au> ???????/???????? ? ???????? ?????????:
> news:44ED8F62.9080508@tpg.com.au...
>
>> Before we look at our own APIs I think it would be a good idea to first
>> agree upon a subversion client library. Right now, the choice of
>> subversion client APIs seems to be the biggest difference between the two
>> proposals.
>>
>> If the decision is made to go with JavaHL we will need to come up with a
>> list of all features it currently lacks and a plan on how to implement
>> them. For instance, we will need the ability to:
>> - Provide our own configuration data so the Java defined http proxy
>> settings can be used (currently possible, but not though JavaHL)
>> - Create an SSH tunnel from Java and have this used from JavaHL
>> - Get access to information on how much data has been transmitted for
>> progress reporting (this is only possible with the SVN protocol at the
>> moment)
>> - Cross WC atomic commit
>>
>> Are there any other major features JavaHL is missing?
>>
>> If we then further decide to use the svnClientAdapter abstraction we will
>> need to look at exposing features of JavaHL that are currently missing,
>> such as the ability to create multiple remote folders in a single
>> transaction.
>>
>> cheers,
>> Brock
>>
>
>
>
|
|
|
| Re: Cooperation Subclipse, Subversive [message #5379 is a reply to message #4986] |
Fri, 01 September 2006 18:06 |
Igor Vinnykov
Messages: 61
Registered: July 2009 |
Member |
|
|
Hello Brock, Mark and other SVN supporters,
As promised, we created document with Subversive architecture overview. This
document provides a review of the project architecture and modules
organization. It describes existing extension points and functionality,
which can be reused by other projects. From the other side it should help us
to follow techical discussions. You can find document there:
http://www.polarion.org/projects/subversive/docs/Subversive_ Architecture_Overview.pdf
We are looking forward for review of Subclipse team as well as other people
in community. What do you think about consistence of used approach,
integration interfaces? Please fill free to share your opinion with us.
Regarding your points, please see below:
> - Cross WC atomic commit
We think that this feature can be included into next JavaHL releases. Isn't
it?
> - Get access to information on how much data has been transmitted for
progress reporting (this is only possible with the SVN protocol at the
moment)
We think that corresponding API should be requested from SVN team. At the
same time it's not a critical feature now.
From our point of view following topics are interested to discuss in
comminity. What is your opinion regarding them?
- Callbacks should be separated on the API level (now one callback is used
in set of cases with different message - question/answer - it is not a good
solution for automated processing)
- JavaHL callbacks API should be used in all cases requiring them, for
example callback on SSH private key currently is absent
- JavaHL client instances should cache connections in order to improve
performance (now it works at the principle "one command-one connection", at
the same time Eclipse IDE plug-in requires another principle support: "one
client-one connection"). This is very important feature from our point of
view.
Best regards,
Igor Vinnykov
|
|
|
| Re: Cooperation Subclipse, Subversive [message #6353 is a reply to message #4986] |
Mon, 09 October 2006 13:45 |
Igor Vinnykov
Messages: 61
Registered: July 2009 |
Member |
|
|
Hello Mark, Brock and Subclipse Team,
Both Subversive and Subclipse projects proposals were published near three
month ago. It was enough time to collect community feedback on proposals and
thoughts regarding future direction. For the Subversive project community
feedback on proposal was extremely profitable and allowed to improve a
project in following areas:
- Integration with other projects. We improved Subversive architecture and
defined set of interfaces, which simplified integration with other projects.
Integration interfaces are described in the document
http://www.polarion.org/projects/subversive/docs/Subversive_ Architecture_Overview.pdf.
Currently Subversive is integrated with Buckminster, FastTrack and Mylar
projects.
- Extend supported features set. We created a special development stream,
which is targeted to Eclipse 3.2/Callisto and contains Eclipse 3.2 specific
features. Additionally we included support of Quick Diff, Live Annotations,
etc. Detailed change log can be found here:
- for 1.1.x:
http://www.polarion.org/projects/subversive/download/1.1/cha ngelog.txt
- for 1.0.x:
http://www.polarion.org/projects/subversive/download/changel og.txt
- Ability to switch between SVN client libraries. Subversive can work with
either with JavaHL-based clients like standard JavaSVN, JavaHL and extended
clients like enhanced JavaSVN. We will enable clients switching as soon as
JavaSVN will provide SVN 1.4 support.
- Build developers community around the Subversive. There are community
contributors, which help with the Subversive development. Those people are
listed in change logs and here:
http://www.polarion.org/index.php?page=patches&project=s ubversive. Moreover
some of them expressed their wish to joined the development team.
There is another area, which should be covered in order to reach the main
goal, which is declared by the Subversive and Subclipse proposals. Seems
that it's clear that community want from us to join efforts of both teams to
deliver a common solution. The Subversive team initiated this discussion a
few times, but unfortunately there is no any progress. Could you please
clarify your position? Our vision is outlined in the updated Subversive
proposal, which quotation you can find below:
----------
A Subclipse project is another SVN plugin for Eclipse. After a publishing of
the Subversive proposal for Eclipse, Subclipse team decided to publish their
own proposal. After reviewing of this proposal we found that both or our
proposals are close to each other and have same goals. The main goal for
Subversive and Subclipse proposals is inclusion SVN support into standard
Eclipse distribution. As so we invited the Subclipse team to join forces in
creation of common project.
Both projects have a good history and a lot of supporters, so from all this
community point of view cancelling of any project in favor of another is not
a profitable way. Instead both teams should join forces in order to analyze
strong and weak points of each solution and create new project, which
benefit from the best solutions. It will not be a quick and easy way, but
it's a good chance to union teams and community in order to reach the main
goal.
In order to make it possible we propose following:
1. Define and agree the approach for analysis of technical solution
2. Identify areas, which should be analyzed and discussed
3. Perform analysis, discuss results and reach an agreement for solution,
which should be selected for new project
The Subversive team made fist steps in this direction and anyone can
contribute to this process. See related discussions in the Subversive
project news://news.eclipse.org/eclipse.technology.subversive newsgroup.
----------
Best regards,
Igor Vinnykov
Subversive Team
|
|
|
Goto Forum:
Current Time: Wed Apr 24 22:47:52 GMT 2024
Powered by FUDForum. Page generated in 0.03287 seconds |
] 
Search
Help
Register
Login
Home
