[cvsnt] newbie branch/merge question

[Nick Duane]

Thank you.  I'll look this over and see how well this will work for us.  The 
one thing that comes to mind at this point (assuming I understand what 
you're saying below) is that the releases are simply tags in the trunk as 
opposed to branches.  Now maybe a symbolic tag and a branch are pretty 
similar, as I said I'm new to CVS so I'm not sure about that.  I'm thinking 
that I would like a branch for each release we intend to make so that we can 
have a well defined place to pull releases from as opposed to just taging 
the trunk at a release.  Plus we often have times when developers are 
working on more than one release at a time and thus we'll need separate 
locations for those.

Nick

"Bo Berglund" <bo.berglund at system3r.se> wrote in message 
news:fajud2pfnigicu2jaribgp1m9k2kea6c1s at 4ax.com...
> On Sun, 13 Aug 2006 11:04:19 -0400, "Nick Duane" <nickdu at msn.com>
> wrote:
>
>>Thanks.  There is some additional information which I did not indicate 
>>which
>>comes into play in how I thought I should put our 3.7.2, 3.7.3, and 3.8
>>releases into CVS.  I believe 3.7.3 was taken from 3.7.2.  However, 3.8 is
>>3.7.2 plus some other changes.  So I can't (at least I think I can't ) 
>>just
>>commit 3.8 to the HEAD.  I was hoping on using CVS's merging capability to
>>merge 3.8 and 3.7.3 for me.
>>
>>Nick
>>
> I suggest you do as follows:
> 1. Import the earliest sources (3.7.2) to CVS
> 2. Tag the result as Rel_3-7-2
> 3. Create a branch Branch_3-8 in preparation for that release.
> 4. Now copy in the files from 3.7.3 to the sandbox where you have
> 3.7.2 and execute cvs status to reveal the files that are actually
> different.
> 5. Examine the sandbox for files that have been added since 3.7.2
> (easily done if you use the WinCvs front end).
> 6. CVS add all of the new files
> 7. Verify that you can build 3.7.3 from these sources
> 8. Commit the sandbox, which now contains 3.7.3
> 9. Tag the module as Rel_3-7-3
> 9. Update the sandbox to branch Branch_3-8 (some files will now
> disappear)
> 10. Copy the sources for 3.8 into the sandbox and execute cvs status
> to reveal the files that are actually different.
> 11. Again look for the files that are new and cvs add these.
> 12. Verify that you can build version 3.8
> 13. Commit the sandbox. This puts all of the sources for 3.8 at the
> tip of branch Branch_3-8
> 14. Create a tag Rel_3-8 on the sandbox files
> 15. Update the sandbox and use te -A flag to remove all sticky tags.
> This puts the sandbox back to current HEAD (= Rel_3-7-3) and the added
> files on the branch will disappear.
> 16. Now update with merge from Branch_3-8. This will put changes on
> the branch inot your sandbox including creating the added files on the
> branch.
> If there are conflicts (there probably are if the scenario you
> dscribed is true) you have to sort these out and make sure you can
> build a test version. When this is done commit the result and tag it
> as Development or similar to signal the base of future development.
>
>
>
> /Bo Berglund