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

[Ben Collins-Sussman <su...@collab.net>]

On Jun 27, 2005, at 11:08 AM, Ben Collins-Sussman wrote:

>
> Rather than get ourselves all tangled in merge-tracking design, I  
> think I'll just imitate this behavior when merging properties.  We  
> can always get more sophisticated later on.
>

Hm, things are uglier than I suspected with our current diff3 text- 
merging.

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?

It definitely points to what ghudson theorized:  that our diff3  
algorithm is *completely* ignoring the text-base.



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

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

[Ben Collins-Sussman <su...@collab.net>]

On Jun 27, 2005, at 3:20 PM, Greg Hudson wrote:
>
> 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.
>

OK, I think I can sleep soundly, our current diff3 algorithm is fine.

If you look at the property-merging file in notes/, I've rewritten  
the pseudocode algorithm to completely ignore the text-base-props.   
I'd be happy if you folks would give it a quick sanity check.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

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

[Greg Hudson <gh...@MIT.EDU>]

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

Re: diff3 merging behaviors

[Philip Martin <ph...@codematters.co.uk>]

Ben Collins-Sussman <su...@collab.net> writes:

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

I haven't been following the discussion, but that merge behaviour
strikes me as perfectly reasonable. Consider the 1.2.x STATUS file:

  * r15157, r15175
    Fix Issue #2343: svn_io_copy_dir_recursively is broken
    Justifcation:
      Prevents a rather simple operation from completing if the
      source path contains the same name as the destination.
    Notes:
      r15175 is a small formatting fix.
    Votes:
      +1: jszakmeister
      +1: kfogel (r15157 only)

The second revision will only apply on top of the local mods produced
by the first revision.

-- 
Philip Martin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org