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.
Glen Starrett wrote: > But the easiest way to get a non-trivial merge to merge in cleanly is to do > as I've outlined, I think. Do you now of a better way? I would think that > with the method you're proposing the dev would be manually merging code > changes into the dev branch instead of CVS automatically merging most of the > updates + a little manual conflict resolution, which seems like a lot more > trouble. I'm still not making myself clear then. CVS's conflict merging is used in my proposal, just as it is in yours. The only manual processing is the [possibly inevitable] manual conflict resolution, which you'd have to do anyway. In fact, with your merge trunk -> branch and branch -> trunk, there is the possibility of two manual conflicts (unless the trunk is frozen during this process). Rather than abstract someone else's work, I urge you to study this section: http://cvsbook.red-bean.com/cvsbook.html#Going_Out_On_A_Limb__How_To_Work_With_Branches_And_Survive_ of the very well written "Open Source Development with CVS" by Karl Vogel (now a core Subversion developer) and Moshe Bar. I personally prefer the "Flying Fish" model which they discuss in some detail, whereas you are using a modified "Dovetail" approach. It depends completely on how independent your development is and how many people are working on each branch (I have a small shop). NOTE: with CVSNT's mergepoint handling, all of the discussion about merging repeatedly with the trunk is moot. You pretty much can merge in either direction without worrying about trying to merge already applied changes. As long as your developers are frequently doing a 'cvs update -j HEAD' on their branch, and cleaning up any conflicts, then it is very unlikely that any conflicts (either textual or semantic) will occur when their branch is merged back to the trunk. It just seems to me like you are waiting to do that until the last moment (when you are ready to merge the branch). There is more than one to do this process. I guess I am saying your process is OK, but you are not doing it often enough. You shouldn't wait until you are ready to merge the branch into the trunk to find out whether the trunk changes are going to break your code. HTH John -- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4720 Boston Way Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5747