multiple merge tricks

[Iakov Glubokiy]

Hello all,

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:

+-----+    +-----+        +-----+    +-----+    +-----+
! 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

If everything above is correct, let's go further.
How would it be correct to merge changes in such a situation?

The only solution I see is the following:
1. Get revision 1.5 (call it ~merged_from_R1fix)
cvs co -r ~merged_from_R1fix module

2. Replace sources in sandbox by its latest version (HEAD), leaving
internal CVS files intact

3. Perform update just as Cederqvist told
cvs update -j ~R1fix_merged_to_trunk -j R1fix

4. Resolve conflicts

5. Obtain another copy of module sandbox and replace sources by merged
ones, leaving internal CVS files intact.

6. Commit changes from the last sandbox

Is here an easier way?

-- 
Best regards,
 Iakov