news <news@sea.gmane.org> wrote on 07/27/2006 10:47:22 AM:
> Mark Phippard wrote:
> > No. We are not providing this because we are basing Subclipse on the
> > capabilities of the Subversion API, specifically JavaHL.
>
> Sorry Mark, I don't see the dependency to JavaHL here. This is a nice
> feature that is provided by the tooling and doesn't need to be supported
> by the underlying library. The only thing you need is the diff and then
> you can build the tree of changes in Eclipse and give the user a nice
> preview.
I do not agree it is that simple. Subversive tries to do this and the
feature just doesn't work. You can get the list of files to display
correctly, but when you ask Eclipse to compare them it is not doing a
correct compare. Eclipse is doing a file compare of the two revisions.
While in some cases, such as when trying to keep a feature branch up to
date with trunk, this will yield the correct result, in other, such as
when trying to backport specific changes from trunk to a release branch it
does not show the correct output as it has no way of taking into account
the "revision range" that you wish to merge.
I have attached a screenshot using Subversive that demonstrates the
problem. In this example, I am working with the Subclipse 1.0.x release
branch and I want to merge the fix made in r2554 in the trunk to this
branch. This is the classic "cherry-pick" merge example that is commonly
used in Subversion development. The screenshot shows that it has
correctly identified the change made in that revision but when I open the
compare editor it is showing the license header changes that have been
committed in trunk in prior revisions. This is totally incorrect. It
should just be showing one line of change as the difference that it was
going to merge.
I also do not like the idea that it allows you to use the editor to
manually merge the changes. How is this going to work with all of the
merge tracking features being added to Subversion right now? How does it
handle binary files?
If someone wants to try to add this feature to Subclipse, I am 100%
supportive of that effort. But I will not accept it into our code base
unless it actually works and addresses these issues.
Thanks
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subclipse.tigris.org
For additional commands, e-mail: users-help@subclipse.tigris.org
- application/octet-stream attachment: merge.png
Received on Thu Jul 27 17:32:38 2006
