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.
Warning: long post, sorry... In reply to Tony Hoyle: Can I just clarify my terms here? I think we might be at cross-purposes in our understanding of the different branch types. This is how I refer to them: 'Development' = a branch used essentially as a place for a developer to save their working copy while they are in the process of writing and testing their code. The code committed to a development branch is work in progress: highly unstable and subject to change. Development branches are short-term and related to a single feature or bug. 'Stable' = a branch used as a collection point for code that developers are satisfied is complete and working as far as they can test. It is stable in the sense that it compiles, and probably will pass any automatic testcases. Developers merge their code to the stable branch only when they are sure that it will not break compilation or auto testcases. *However*, the code has not yet been fully system tested and is not ready for customer release. Many development teams use HEAD as their stable branch. (I think this might be what you are calling the development branch.) 'Candidates' and 'Releases' = often done by tagging the stable branch, these represent freezes of the code to undergo full system/verification testing in preparation for full release. Sometimes separate branches may be used for candidate and release code; if so, developers never merge code directly into these branches in case they break the testing that has been done on them so far. (I think that when you refer to the stable branch, this is the type you mean.) So in these terms, a development branch is right down at the bottom of the pecking order. Because of its instability, it isn't practical or desirable for developers to share a development branch. Each developer is working towards the goal of getting their code ready for addition to the stable branch; and to do this, they must periodically make sure that their development branch is 'up to date' by merging to their own development branch any code that other developers have recently added to the stable branch. In this way they make sure that when they merge their code into the stable branch, there are no surprises and nothing breaks. It is possible (even likely) that when such an 'updating' merge is done from the stable branch to the developer's branch, developer B might find that changes on the stable branch made by developer A have affected his code - a conflict has arisen in some library code, maybe, or perhaps A has changed some core function such that B has to revisit his design. Under these circumstances A and B will talk to each other, agree how to resolve the problem, and B will make changes *on his development branch* such that when his code is included, A's code will continue to function properly. Then when B is confident that he is up to date with the stable branch, he puts his code into that branch by merging back. The code that he merges back will contain the changes necessary to get his code and A's code to work together, i.e. A's code has been changed, but this has been done in consultation with A. Also B has verified code stability (compilation, testcases) *before* anybody else is affected. I hope this makes things a little less confused. -- Tony