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.
Tony Hoyle wrote: > Normally there would be one development branch. > [...] > Yes but there's never a merge from the stable to development. > [...] > No it isn't - stable is stable and is the tested results of > development. I think there may be a misunderstanding of what I mean by 'stable' and 'development - see previous post. > I explained why before with a separate example. Here's > another more complex one (that may end up in the ebook at some point): > > Branch B > Start feature changes, Commit a few times Merge from A More > changes to incorporate changes to A. Had to bugfix A as it > broke your changes. > More feature development. > Merge from A > Feature gets tested > Merge from A. > Changes to fix feature as it broke again. > Feature gets tested. > Merge from A. > Test passed. > Merge back to A. > > This shows several points: > > 1. Merging from the mergepoint would completely lose all the > changes. > You *must* merge from the branchpoint. What changes have been lost? All the original commits to A are still there, and the head of A now has the necessary changes to allow A and B to work together. What would the merge from the branchpoint have saved? > 2. The methodology used has caused conflicts because the > developers weren't in communication - the final merge may > break the tree entirely because the developer had to change > code that wasn't his own to make his code work. That's normal code development - features often interact, or use common (library) code in conflicting ways that need to be resolved. In these circumstances, B would if possible discuss the problems with the relevant designer before making the changes; at any rate, it is B's responsibility not to break the existing functionality on A when he merges back. -- Tony