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.
> 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_Wi th_Branches_And_Survive I've previously read that, actually. Re-reading it again with knowledge and experience in working with it makes it clear to me that the text is __very__ out of date relative to CVSNT. Mergepoints have eliminated the need to tag before branches and after merges, so 3/4 of the volume of text in those sections is unnecessary (tag, tag, remember which tag, and keyword expansion is no longer the enemy). I'm thinking the cvsnt wiki could use another update with some of that information... > 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). I'm always telling my devs to update more often, but they don't always listen :). We also divide the functions individuals are working on to minimize conflicts which prevents the majority of issues right away. Until they are ready to call their code complete, they are often reluctant to update and potentially break their sandbox. I certainly agree though that it is MUCH better to update often than have a long-lived branch that ends up with a lot of conflicts (or worse, non-conflicting logic changes). Definitely a thought-provoking discussion. Thanks! Regards, Glen Starrett