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.
Dianne, Your software control process makes me cringe. :-) Branching the source and then merging the branch back in later is sometimes necessary, but it is alway tedious. Your appear to be planning N+1 tedium with one branch per developer plus an integration branch. In my experience, you want to reserve branching for things that can't be done anyother way, so that most of the work is always on the trunk. In your plan, _none_ of the day-to-day work is on the trunk. Furthermore, the integratoin branch adds yet one more level of conflict. First, consider the trunk and the integration branch. Why keep them separate? You can accomplish the same thing with tags. When the development gets to the point that it is ready for testing, the project manager tags the ready-for-testing versions of all the files with a well-known tag, such as TEST_RELEASE. Your testing people simply extract using that tag rather than defaulting to the HEAD. Your testing people don't know (and don't care) if there are any later revisions of any of the files they extract. They get the TEST_RELEASE files and that's that. If several iterations of testing are necessary, then so be it. Each time the source base is thought to be ready for test, the project manager moves the TEST_RELEASE tag to the new revisions and tells the testing people to do it again. When a version finally passing testing, the project manager attached a tag, say, RELEASE_xyz, to all file revisions currently having the TEST_RELEASE tag. Your method apparently allows everyone to always work off the HEAD revision of a branch or trunk--but that is a small advantage over specifying a checkout tag rather than taking the default. Now, consider your developer branches. The only reason a developer _should_ work on a personal branch is if that developer is actually experimenting with several alternate solutions and doesn't want to mess up any other developers until he can decide on which alternative to use--but I don't think this is what you are doing. In general, each developer should work off the trunk. As each feature or bug fix is added, those files are committed together back to the trunk. In this manner, the trunk incrementally grows toward the next release. At the same time, each developer should periodically (once a day?) update his sandbox so that he will see whatever else other developers have done. In this way, conflicts are seen early, when they are small and much, much easier to correct than during massive merges at the bitter end. Merrill