Nestor,

Yes, this does make sense.  It would accomplish the desired goal of not
having the same code merged twice (which would result in conflicts).  It
would require possibly 2 passes of conflict resolution for each of the
updates.  For the problem as I presented it, your suggestion looks to be the
right way to do it.

I also received a the following suggestion:
...snip
The easiest way might be to change the way you branch.  Instead
of branching out release2 when release1 nears completion, make
a branch for release1 and continue new feature devolopment for
release2 on the main trunk.  Merge release1 bugfixes from the
release1 branch to the trunk.  When release1 is finished,
use the release1 branch for maintenance fixes.  This way you
get a branch for each release, but development can continue
on the main trunk.
...snip

This is probably what I should be doing - it eliminates the
"multiple-merging" from trunk-to-branch followed by branch-to-trunk.
Following the suggestion, merging is only performed unidirectionally from
the branch to the trunk which simplifies things a great deal.

Thanks for your replies,
David Martin





>What if you do two merges into the trunk? First, you need the earlier
>changes:
>
> cvs update -j BUILD1234 -j BUILD1234_REL2_MERGED_WITH_BUILD4567
>
>Then, upon checking that in, you do the following merge to get the
>remainder:
>
> cvs update -j BUILD1234_REL2_MERGED_WITH_BUILD4567 -j
>BUILD1234_REL2_BRANCH
>
>Please let me know if this makes sense.
>
>Nestor
>
>-----Original Message-----
>From: David L. Martin [mailto:[EMAIL PROTECTED]]
>Sent: Tuesday, May 30, 2000 10:23 AM
>To: [EMAIL PROTECTED]
>Subject: Need Merging Advice
>
>
>Hello,
>
>I need some advice on how to best perform a merge in the scenario
>below.  This mimics a real-world example that was just performed, and I
>would welcome pointers on how to improve the process.
>
>We're using the trunk for work on the next product release, and branches
>are created for experimental work, future release work, and post-release
>maintenance.  Development towards Release 1 of the product progresses on
>the trunk.  Before Release 1 is complete, work on Release 2 commences by
>creating a branch off the trunk at a specific tag (BUILD1234).  The
>branch is named BUILD1234_REL2_BRANCH.
>
>Work progresses independently on both trunk and branch for a couple of
>weeks.  Release 1 modifications are made to the trunk, and Release 2
>features are added to the branch.  At some point, the Release 2 branch
>developers realize they need bug fixes made on the trunk since their
>branch was created to continue with their work.  The latest trunk code
>tag is BUILD4567, and the latest (fixed) tag on the branch is
>BUILD1234_REL2_BUILD5.  Code from the trunk is merged to the branch (on
>the branch, with cvs update -j BUILD1234 -j BUILD4567) and committed.
>The branch code is tagged BUILD1234_REL2_MERGED_WITH_BUILD4567.
>
>Work again progresses on the trunk and the branch until we get to the
>point where the code on the trunk towards Release 1 is complete.  A
>branch tag for Release 1 maintenance is created.
>
>Now we want to merge the code from the Release 2 branch  to the trunk.
>The latest trunk code tag is BUILD5432, and the latest (fixed) tag on
>the branch is BUILD1234_REL2_BUILD10.  From the trunk, I issue a cvs
>update -j BUILD1234_REL2_BUILD10.  Here's where the problem comes about
>- I get conflicts on "remerging" changes which had already been merged
>to the branch and are now merged again to the trunk.  If I issue from
>the trunk a cvs update -j BUILD1234_REL2_BUILD5 -j
>BUILD1234_REL2_BUILD10, I don't get the changes made on the branch
>between BUILD_1234 to BUILD_REL2_BUILD5.
>
>We had about 54 conflicts on the merge to the trunk, most of which were
>easily resolved, but I suspect there should have been only about 10
>conflicts if I'd done it right.  I suspect I needed to do something like
>create a new branch on trunk revision BUILD_4567 (call the branch tag
>BUILD_4567_BRANCH), and then merge the changes onto this branch between
>-j BUILD1234 and -j BUILD1234_REL2_BUILD5.  I could then have used the
>following command to merge back to the trunk:  cvs update -j
>BUILD_4567_BRANCH -j BUILD1234_REL2_BUILD10.
>
>Does this sound right?  Is there an easier way?
>I appreciate your responses...
>
>David
>
>
>

Reply via email to