Re: multiple merge tricks

[Kaz Kylheku]

On Thu, 26 Feb 2004, Iakov Glubokiy wrote:

> I'd like to discuss some thoughts about merging from a branch several
> times. AFAIU, Cederqvist ommited the tiny fact that using double -j
> one can lose some data. He says:
> 
> ====
> Continuing our example, the revision tree now looks like this:
> +-----+    +-----+    +-----+    +-----+    +-----+
> ! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 ! <- The main trunk
> +-----+    +-----+    +-----+    +-----+    +-----+
>                 !                           *
>                 !                          *
>                 !   +---------+    +---------+
> Branch R1fix -> +---! 1.2.2.1 !----! 1.2.2.2 !
>                     +---------+    +---------+
> where the starred line represents the merge from the ‘R1fix’ branch to
> the main trunk, as just discussed.
> Now suppose that development continues on the ‘R1fix’ branch:
> +-----+    +-----+    +-----+    +-----+    +-----+
> ! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 ! <- The main trunk
> +-----+    +-----+    +-----+    +-----+    +-----+
>                 !                           *
>                 !                          *
>                 !   +---------+    +---------+    +---------+
> Branch R1fix -> +---! 1.2.2.1 !----! 1.2.2.2 !----! 1.2.2.3 !
>                     +---------+    +---------+    +---------+
> ====
> 
> well, in that certain case suggested
> 
> cvs update -j 1.2.2.2 -j R1fix m.c
> 
> works fine.
> But in more common case, when the trunk was changed too, we can
> overwrite changes in trunk by changes in the branch! Where single -j
> update produces conflict, double -j produces overwrite. Look:

That is not by design. If you actually have a test case that reproduces
an instance of overwrite, you should discuss that.

> 
> +-----+    +-----+        +-----+    +-----+    +-----+
> ! 1.1 !----! 1.2 !--...---! 1.5 !----! 1.6 !----! 1.7 ! <- The main trunk
> +-----+    +-----+        +-----+    +-----+    +-----+
>                 !               *
>                 !                 *
>                 !   +---------+    +---------+    +---------+
> Branch R1fix -> +---! 1.2.2.1 !----! 1.2.2.2 !----! 1.2.2.3 !
>                     +---------+    +---------+    +---------+
> 
> Here
> 
> cvs update -j 1.2.2.2 -j R1fix m.c
> 
> conflicting changes at 1.2.2.3 just discard changes at 1.6-1.7

Conflicting changes should produce conflict markers.

You should see a 3-way merge performed with 1.2.2.2 as the ancestor,
and 1.7 (your working copy) and 1.2.2.3 as the two descendants.

Your approach can produce bad merges in a different way. If you use the
tip of the branch as the second argument to -j, you have potential race
conditions between the merge and other people doing commits on the
branch:

  cvs update -j branch_x_last_merge -j branch_x

  #  resolve conflicts, commit
  #  ... meanwhile more changes are added to branch ...

  cvs tag -F -r branch_x branch_x_last_merge

  # last merge tag is moved to the tip, skipping over new changes!

Always place a stable tag at the tip of the branch, and then merge to
that. Use that tag as the starting point for the next merge.