| Subclipse SVN proposal submitted to Eclipse [message #2215] |
Mon, 24 July 2006 14:24  |
Eclipse User |
|
|
|
Originally posted by: markp.softlanding.com
I see from a post in this thread on the Subversive forums that you are
already aware that the Subclipse team has been working on a proposal
for adding Subversion support to Eclipse.
http://forums.polarion.org/viewtopic.php?t=355
I just wanted to let you know that this AM we officially submitted the
first draft of our proposal to Eclipse. Until it is posted on
Eclipse.org, you can view what we submitted here:
http://subclipse.tigris.org/proposal/index.html
As it says in the proposal, we look forward to the opportunity to
discuss whether our projects can work together towards the common goal
of adding Subversion support to Eclipse.
Thanks
Mark
|
|
|
| Re: Subclipse SVN proposal submitted to Eclipse [message #2305 is a reply to message #2215] |
Thu, 27 July 2006 15:08  |
|
Mark Phippard wrote:
> As it says in the proposal, we look forward to the opportunity to
> discuss whether our projects can work together towards the common goal
> of adding Subversion support to Eclipse.
Thanks for posting the link. However, I came across the following
posting from you.
http://subclipse.tigris.org/servlets/ReadMsg?listName=users& amp;msgNo=7020
> Mark Phippard wrote:
>> I do a lot of merges, and I personally cannot see the value in this
>> feature. I suspect that is because I am very familiar with Subversion and
>> its approach to merge, and do not have any real CVS experience. Anyway,
>> after doing a merge into your working copy you can do Compare with -> Base
>> Revision to get an accurate picture of everything the merge did. This can
>> then be edited/refined or even just use Team -> Revert if you want to undo
>> it. This approach performs well, is 100% accurate/consistent with
>> Subversion and lets you leverage the automation of the Subversion merge
>> process.
Now I'm a bit concerned about the kind of integration into Eclipse that
this proposal will provide. It looks like that you try to stay as close
as possible to the Subversion base. For me this sounds like having an
Eclipse Subversion plug-in in the end that is just a copy of TortoiseSVN
from a UI point of perspective.
However, I would rather see an Eclipse Subversion plug-in that
integrates nice with the Eclispe workflow (the Eclipse "Way") without
reimplementing the Subversion communication protocol. But this also
means stepping back from some traditional TortioseSVN-like interactions.
Maybe I'm just too pessimistic but I read an undertone in both proposals
which sounds pretty much like: "Yeah, we invite the other guys to join
us. However, we are the project lead and we decide what contribution we
accept."
I appreciate the Subclipse project very much. It was the first usable
Eclipse Subversion client out there. I still prefer it in terms of
stability. However, I also admire what the Subversive developers have
built. Subversive sticks out especially in the perspective of a smooth
integration with the Eclipse workflow and the UI area.
--
Gunnar Wagenknecht
gunnar@wagenknecht.org
http://wagenknecht.org/
|
|
|
| Re: Subclipse SVN proposal submitted to Eclipse [message #2425 is a reply to message #2305] |
Thu, 27 July 2006 18:29 |
| Eclipse User |
|
|
|
Originally posted by: markp.softlanding.com
Gunnar Wagenknecht wrote:
> Now I'm a bit concerned about the kind of integration into Eclipse
> that this proposal will provide. It looks like that you try to stay
> as close as possible to the Subversion base. For me this sounds like
> having an Eclipse Subversion plug-in in the end that is just a copy
> of TortoiseSVN from a UI point of perspective.
I do not think that is the case at all. I gave an answer and then
stepped back to give personal opinion about how I use the tool and I
have to do SVN merges almost every day. I have also been clear in the
past that I do not use the Synch view very often, but I have certainly
invested plenty of time in supporting it.
Subclipse is a community effort. I do not believe we have ever turned
down any contribution that was made to completion and I have added many
features that I was initially against. My only concern with he
interactive merge feature is that I have concerns that it can ever be
made to work properly. I am also concerned about how it would interact
with the merge tracking feature being added in Subversion itself. In a
multi-tool project you would not want the actions of a single Eclipse
user to negate some Subversion feature that others are using from the
command line. As long as these issues can be addressed, I'd be
ecstatic to include a feature like this in Subclipse as I know there
are users that want it.
> However, I would rather see an Eclipse Subversion plug-in that
> integrates nice with the Eclispe workflow (the Eclipse "Way") without
> reimplementing the Subversion communication protocol. But this also
> means stepping back from some traditional TortioseSVN-like
> interactions.
I would not say that we base ourselves on TortoiseSVN. When I was
initially adding a lot of the dialogs we needed in Subclipse, I
certainly looked at how they gathered the information and validated it
etc. Other than that, there has not been any desire to copy them.
This is all stuff that happened two years ago now.
> Maybe I'm just too pessimistic but I read an undertone in both
> proposals which sounds pretty much like: "Yeah, we invite the other
> guys to join us. However, we are the project lead and we decide what
> contribution we accept."
I can only speak to the Subclipse proposal. If Polarion wanted to join
our project and bring in some of their features that we do not have, we
would welcome them and their contributions as well as give them full
committer status which makes them an equal of every one else. They
would just have to abide by the wishes of the community as all the
other committers do. I have not seen anything that they have done with
Subversive that I would not be willing to include in Subclipse
(provided of course that it works correctly).
Mark
|
|
|
| Re: Subclipse SVN proposal submitted to Eclipse [message #2456 is a reply to message #2425] |
Thu, 27 July 2006 20:19 |
|
Mark Phippard wrote:
> [...] In a multi-tool project you would not want the actions of a single Eclipse
> user to negate some Subversion feature that others are using from the
> command line.
I agree. That is an important requirement. But isn't it up to the
tooling to ensure that the merge tracking is properly supported?
> I can only speak to the Subclipse proposal. If Polarion wanted to join
> our project and bring in some of their features that we do not have, we
> would welcome them and their contributions as well as give them full
> committer status which makes them an equal of every one else. They
> would just have to abide by the wishes of the community as all the
> other committers do. I have not seen anything that they have done with
> Subversive that I would not be willing to include in Subclipse
> (provided of course that it works correctly).
Thanks for clarifying on this.
Cu, Gunnar
--
Gunnar Wagenknecht
gunnar@wagenknecht.org
http://wagenknecht.org/
|
|
|
| Re: Subclipse SVN proposal submitted to Eclipse [message #2483 is a reply to message #2456] |
Thu, 27 July 2006 20:24 |
| Eclipse User |
|
|
|
Originally posted by: markp.softlanding.com
Gunnar Wagenknecht wrote:
> Mark Phippard wrote:
> > [...] In a multi-tool project you would not want the actions of a
> > single Eclipse user to negate some Subversion feature that others
> > are using from the command line.
>
> I agree. That is an important requirement. But isn't it up to the
> tooling to ensure that the merge tracking is properly supported?
Subversion is a bit different than CVS in the sense that virtually
every tool that exists uses the Subversion libraries. So
compatability/consistency is generally not an issue. My only point
here was that if you are doing an interactive merge and the user opens
the editor, manually makes changes and saves them, then the normal
Subversion merge "API" is not being executed. So you would potentially
be losing the "free" compatability you would get from running the merge
API.
But yes, the larger point is that this is simply one more thing that
will need to be taken into account by someone adding the feature. I
did not mean to imply that it will be an insurmountable problem.
Mark
|
|
|
|
| Re: Subclipse SVN proposal submitted to Eclipse [message #2543 is a reply to message #2513] |
Fri, 28 July 2006 00:34 |
| Eclipse User |
|
|
|
Originally posted by: markp.softlanding.com
Gunnar Wagenknecht wrote:
> Mark Phippard wrote:
> > Subversion is a bit different than CVS in the sense that virtually
> > every tool that exists uses the Subversion libraries. So
> > compatability/consistency is generally not an issue. My only point
> > here was that if you are doing an interactive merge and the user
> > opens the editor, manually makes changes and saves them, then the
> > normal Subversion merge "API" is not being executed. So you would
> > potentially be losing the "free" compatability you would get from
> > running the merge API.
>
> If I read the specs correctly. There will probably be an API to record
> such a manual merge. :)
>
> http://svn.collab.net/repos/svn/branches/merge-tracking/note s/merge-tr
> acking.txt
Yes, that is correct, I recall discussions that there would be an API
for this to handle manual merges.
Our group is now up, so we should probably continue any discussions
relating to Subclipse on that group.
The group name is eclipse.technology.svn
Thanks
Mark
|
|
|
Powered by
FUDForum. Page generated in 0.02464 seconds
] 
Search
Help
Register
Login
Home
