[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [Subclipse-users] desired feature: preview the merge in the synchronize view

From: Mark Phippard <markp_at_softlanding.com>
Date: 2006-07-27 20:08:27 CEST

news <news@sea.gmane.org> wrote on 07/27/2006 01:53:20 PM:

> 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 beleive that only works if the "third" item is a common parent to the
other two files. In this example, it is not. Eclipse compares your local
file to this "third" item too and that is what causes the difference.

> > 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.

I went a little further with the Subversive example. If you take their
option to update all it appears to revert back to doing a Subversion
merge. So that would handle merging binaries like JAR's.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subclipse.tigris.org
For additional commands, e-mail: users-help@subclipse.tigris.org
Received on Thu Jul 27 20:08:42 2006

This is an archived mail posted to the Subclipse Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.