Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
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