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.
Bo Berglund 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. >> > 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 I think here is missing a check for files that are in 3.7.2 but not anymore in 3.7.3; that is, files that have been removed from the project. For that you have two options: Either you don't only copy in step 4, but rather delete all project files (version 3.7.2 -- but do /not/ delete all the CVS subdirectories and any files in them) and then copy the 3.7.3 files in, or you run a directory compare utility and see which files have been removed in 3.7.3. If you use the first option, WinCvs for example will show you which files have been removed. In any case, these files should be "cvs remove"d from the repository before committing. > 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. Same here about files that have been removed. (Not removing files that are not longer part of the project is often not necessary for a build, and the build will often work whether you remove them or not, but I consider it still a good thing to do. And there are situations where not removing a file does affect the build result.) > 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. What Bo is describing is based on the assumption that a Branch_3-8 is more useful to you than a Branch_3-7-3. If a Branch_3-7-3 would be more useful (say because you want to continue providing bug fix support for that release), you can reverse the instructions (exchange 3.7.3 and 3.8 in the instructions). The instructions work both ways, and the end result on HEAD should be the same (depending on your merging, of course :). The only difference is what version you have on the one branch you create when following the instructions. And answering your other message: yes, HEAD is the cvs(nt) name for the trunk. Wherever you can use a branch name in cvs(nt) commands, you can use HEAD to refer to the main branch/trunk. Gerhard