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

Re: diff3 merging behaviors (was Re: svn commit: r15164 - trunk/notes)

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2005-06-27 22:20:48 CEST

On Mon, 2005-06-27 at 11:54 -0500, Ben Collins-Sussman wrote:
> cmpilato and I were discussing a scenario where the server wants to
> change a single line of text from A to C, and in the working copy,
> the text-base is Q, with a local mod that changes it to A.
> Amazingly, 'svn merge' overwrites the existing local-mod as a clean
> merge. 'svn diff' then shows Q changing into C. The original local-
> mod is gone; reverting takes the line back to Q, rather than A.
> Is this a known behavior? Is it bad?

Well, it's certainly what I would expect. "svn diff" sees that the
common ancestor and one target (the wc copy) have 'A', and the other
target (the merge target) has 'C'.

I'm not sure why the text base is necessarily important. If a previous
revision changed A to Q and another previous revision changed Q back to
A, we wouldn't expect the merge to pay any heed.

I guess the potentially disturbing thing here is that the local mods
have not necessarily been recorded yet, and can be lost as a result of
the merge operation. But why would I be doing a merge on top of local
mods in the first place? Generally, I'd only do that if I were doing a
sequence of merge commands, such as if I were creating a 1.2 backport
branch. In that case, I would be pretty frustrated if the text base got
in the way of performing a clean merge.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jun 27 22:22:17 2005

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

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