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. _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
