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

Re: svn merge produced conflict with bad merge

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2004-08-11 20:35:43 CEST

On Wed, 2004-08-11 at 11:58, Kevin Ballard wrote:

> If you look, the left side contains my working code and the right side
> contains the "conflict", which if I decided I'd want to toss my working
> code and use the "new" code I'd lose 2 drawing operations *which are
> present in the left and right merge files* (although slightly
> modified). This is very disturbing to me.

You're making a incorrect assumption about 3-way merging: resolving
conflict markers isn't always about "choosing one side or the other".
It's _not_ the case that one side of the marker is always correct, and
all you have to do is select it. Conflicts aren't always that simple.
There situations where choosing an entire 'side' of the conflict is
guaranteed to lose code, no matter which side you choose.

In these situations, you have to do a manual semantic (human) merge of
code; the conflict markers are only showing the troubled region, not
offering you a black-and-white choice.

I don't know the diff3 algorithm intimately, but I can hazard a guess as
to what's happening in this specific case. The [_title] block is
showing up in the 'working' area of the conflict because it's locally
modified in the working file. It's not in direct conflict with the
repository files (the repos files never changed that line), but it's
probably shown anyway because it's "close enough" to the real conflicts,
and thus falls within the 'troubled contextual region'.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Aug 11 20:37:35 2004

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

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