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.
Nick Duane wrote: > Let me add a bit more complexity to this before letting this post rest in > peace. I have also made some changes to 3.7.2 centered around cleaning up > the build. Ideally I would like these changes applied to a 3.7.2 build in > CVS (maybe called 3.7.2.5) so that I can get back to it later. For sure I > need these changes applied to the current 3.8 code base. So with that being > said would the following be reasonable? > > * Add current 3.7.2 code to CVS > * Tag as 3.7.2 > * Create 3.7.2 branch at 3.7.2 tag So far sounds good. > * Apply my changes to trunk > * Tag as 3.7.2.5 I'm not sure this is what you meant. If you apply your 3.7.2.5 changes to the trunk (HEAD), why did you create a 3.7.2 branch above? This 3.7.2 branch would usually be where further improvements to that version would go; that's the purpose of the branch. So maybe you think about applying these changes to the 3.7.2 branch, then merge them back to the trunk (which should be straightforward without conflicts, as no conflicting changes happened on the trunk). One reason for this is that you may find some more things that you want to fix on that 3.7.2 version. Where would you put that if you have the 3.7.2.5 version on the trunk rather than on the 3.7.2 branch? Following that some reasoning, the 3.7.2.5 code would be tagged on the branch, not on the trunk. > * Create 3.7.3 branch from 3.7.2 tag > * Copy 3.7.3 code to 3.7.3 branch > * Merge 3.7.3 into trunk > * Tag as 3.7.3.5 This tag (if I understand you correctly on the trunk) looks strange. For me, all tags related to the 3.7.3 release should be tagging code on the 3.7.3 branch. The code on the trunk after the merge does not exist in that version on the 3.7.3 branch -- which is where /all/ 3.7.3 code is supposed to be. So having a 3.7.3.? tag that's not on the 3.7.3 branch is extremely confusing. If you want to have your 3.7.2.5 changes in the 3.7.3 branch, you need to merge them there. You don't do that with your procedure. > * Create 3.8 branch from 3.7.2 tag > * Merge trunk into 3.8 branch Not good. Starts bi-directional merging, as later you will want to merge your 3.8 development back to the trunk. The question here is why you want to have a 3.8 branch. You only need a branch when you actually "branch"; that is, when you have two lines of development that separate. What would be on HEAD after the 3.8 branch? It seems to me that 3.8 is your current most advanced line of development. Unless there is another, more advanced line of development, that's probably quite fine on HEAD. > By the way, my changes consists of several renamed directories and files > (copy and delete) as well as other changes. Not sure how well > directory/file renames merge. They are basically a combination of remove/add. This doesn't merge well. That is, the remove/add itself merges fine, but it doesn't consider any changes between the removed and the added file. Say you have file A on the trunk. You branch it, and on the branch you "rename" it to file B (that is, you remove file A and add file B). Then you make some changes to file B. In the meanwhile, on the trunk, you make some changes to file A. Now you merge the branch into the trunk. It will detect that file A has been removed and file B has been added, and that's what it will do to the trunk. It will /not/ merge the changes you made to file A on the trunk with the changes you made to file B on the branch, as it really can't know that they are the same file. This is something you have to do manually, using 3-way comparison tools and a lot of attention to catch all these cases :) Gerhard