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