The suggested model is the one I usually use and recommend. You will still
need Nestor's merge method to avoid conflicts when you merge to the trunk a
second and subsequent times. The extra tagging isn't a bad idea, anyhow - it
makes it easier to back out changes if you ever make mistakes, too. Not that
I ever make any mistakes, but it pays to be careful. ;)
Derek
--
Derek Price CVS Solutions Architect
mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com )
--
126. Always proof-read carefully to see if you any words out.
"David L. Martin" wrote:
> 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
