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 firstname.lastname@example.org.
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