[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: Kevin Ballard <kevin_at_sb.org>
Date: 2004-08-11 20:40:18 CEST

Thanks for the clarification. I've only done 2-way diffs before and in
there you can choose one side or the other and not lose code (although
you sometimes want to hand-merge it as well).

On Aug 11, 2004, at 2:35 PM, Ben Collins-Sussman wrote:

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

-- 
Kevin Ballard
kevin@sb.org
http://www.tildesoft.com
http://kevin.sb.org

  • application/pkcs7-signature attachment: smime.p7s
Received on Wed Aug 11 20:40:52 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.