I just wanted to share what we did at my previous company:
We had a trunk branch, an intermediate branch and 5-10 different sub branches, each with its own sub focus of the code base (graphics, ai, etc). Ever developer submitted his/her change to a sub branch. Then on a round robin schedule, the lead developer from each branch took a day to merge the sub branch with the intermediate branch and sync the two and get it up and running.
Once a sub branch was merged with the intermediate branch, the testers began to test it. If the tests passed, intermediate was merged with trunk.
Problems that occurred was that some changed in the different sub branches was needed in another sub branch right away. Often this was circumvented by merging the specific change list into the sub branch that needed it. The whole system felt a little bit clumsy, but was there to not interrupt everyones work if someone made a commit that crashed the build.
Maybe too complicated, but just a real life example...
-G
Aleksey Bragin wrote:
Herve suggests using a kind of a continuous integration system, describing it this way:
- precommit hook
if commit not to trunk, abort precommit hook create a REV-abc branch from trunk and do the commit here
- regularly
go through all REV-abc branches (increasing ABC numbers) test it if not, inform user or whatever that test failed and go to next branch try to merge to trunk if not, inform user or whatever that merge failed and go to next branch commit to trunk delete the branch go to next branch
- pros:
devs and users will have new version to trunk once they are tested devs and users only have to know trunk
- cons:
changes are not immediatly available for everyone, except in REV-abc branch
On Oct 3, 2007, at 12:50 PM, Aleksey Bragin wrote:
Hello, recently, different people raised a question: How should development process evolve with time, when ReactOS has more (much more) developers willing to contribute code?
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev