At 09:55 13.05.2002 -0700, Mark Womack wrote: >> Working with branches is not completely trivial and requires a little >> coordination between committers, in particular in relation with branch >> merge operations. In order to avoid multiple merge conflicts, each >> time we merge from the 1.2 branch to the main trunk, we should (must?) >> tag the merged version on the 1.2 branch. Subsequent merges should use >> the tag referring to the latest merged version of the branch. Also do >> not forget to publicly announce a merge operation.
>Are you implying that changes applied to the 1.2 branch should not be >applied to the main trunk? That those changes should wait for a merge of >the 1.2 branch back onto the main trunk? Essentially, yes. I am suggesting that (1.2 -> trunk) merge operations be done in a concerted manner. Before doing a merge you tell everyone that you are going to do a merge, merge, and then tag the merged version on the 1.2 branch, for example v_1_2_-merged-lf5. The *next* merge operation would be performed as cvs update -j v_1_2_-merged-lf5 -j v1_2-branch from within a working copy of the trunk. From reading the CVS manual, this eliminates the side effects of merging already merged changes. Does it sound reasonable? >I have always found working with branches to be fairly straightforward once >you have the branch checkout, etc. But I have rarely been able to escape >merge conflicts. There is always something that throws cvs off when it >merges, and I end up cleaning something up by hand. Side effects of merging already merged changes? >-Mark -- Ceki -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
