|Re: Subclipse SVN proposal submitted to Eclipse [message #2305 is a reply to message #2215]
||Thu, 27 July 2006 15:08
|| Gunnar Wagenknecht
Registered: July 2009
Location: San Francisco ✈ Germany
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.
> 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
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
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.
|Re: Subclipse SVN proposal submitted to Eclipse [message #2543 is a reply to message #2513]
||Fri, 28 July 2006 00:34
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
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
Powered by FUDForum
. Page generated in 0.10386 seconds