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 Eva wrote: > Umm... I think we have a failure to communicate here, because > that's what I said (or thought I said). However, we do seem > to agree that the developers work on a development branch > (perhaps several development branches). Let us assume that Normally there would be one development branch. In fact it's difficult to imagine a scenario where there would be multiple ones... if your developers depend on each other they must be on the same branch. If your developers are working on completely independent code then they might as well be in the same branch as they won't conflict. > the intention is for the work that is done on the development > branch to be added to the stable branch when it (the > development branch) is tested and stable. That means there > must be at least one merge from the development branch back > to the stable branch, not so? Otherwise the development will > never be included in the stable build. Yes but there's never a merge from the stable to development. > So it is fair to postulate a series of merges from the stable > branch to the development branch, culminating in one merge > back from the development branch to the stable branch at the > end. No it isn't - stable is stable and is the tested results of development. If there is every anything in stable has not come from development then something is badly wrong. > This is the scenario that CVS does not seem to handle - > specifically, the one final merge back to the stable branch, > where in my view the ancestor (or merge base point) is > incorrectly determined. It is absolutely correct and it *is* an unsolvable problem. 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. 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. Tony