Mark Phippard wrote:
> 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.
AFAIK this case should be solvable by performing a three-way compare
using the preceding version of the trunk file as base. The comparer
would than generate a diff between the preceeding version and the
branched version and use this as a filter. I wonder if Eclipse already
implements this compare algorithm. But I have to admit that I only
implemented two way compares in Eclipse before. But I do remember that
the Eclipse Compare support should allow a three-way compare.
> 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?
You don't even need binary files for it. The problem already happens
with XML files. That's where the extensibility jumps in. It's actually
possible to "overload" the compare/merge editor for any specific
content. That's part of the model based compare/merge support. Of
course, that is out of scope for any team provider.
Cu, Gunnar
--
Gunnar Wagenknecht
gunnar@wagenknecht.org
http://wagenknecht.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subclipse.tigris.org
For additional commands, e-mail: users-help@subclipse.tigris.org
Received on Thu Jul 27 19:54:29 2006