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.
--- Merrill Cornish <merrill.cornish at earthlink.net> wrote: > 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 > Thanks for the reply, Merrill. You raise interesting questions. First off, I omitted that this is for a company that does small, embedded firmware, typically less than 12K. Team sizes are 5 or less, and usually size of 1, 2. I don't think this changes anything - but may for others providing input. So do all of your developers modify a lot of the same files? Is that what is driving the need for constant merge? If developers modify different files, is a merge from a developer branch to integration branch all that hard? It could be my past experience with large, excrutiatingly partitioned systems is coloring my thinking. ;) Your trunk and my integration branch are the same ideas then, yes? A place where efforts are merged to? If yes, than you certainly got rid of my integration merge to trunk. Are you able to provide metrics/diffs from non-consecutive releases (i.e., from one tag to another tag, with many merges to trunk in between)? In your example of TEST_RELEASE, do you mean that you move the label itself? Or was your example simplified to make the point. (In your example, the Test dept would have 2 different piles of code, both from tags TEST_RELEASE!) I am interpretting your example to say that you would move the "intent" of the TEST_RELEASE tag, as in make a TEST_RELEASE_1 tag, make a new tag TEST_RELEASE_2, etc.). Is this correct? My environment is a little harsher for proving traceability, and I suspect moving a tag would not be allowed. So it looks like you advocate no developer branches. Hmm. Is my understanding correct then? The developer gets a version of code in their working directory, makes changes, tests it, and then merges it back to the trunk. No branches, right back to the trunk. Do you need to provide metrics for the effort provided by each developer (i.e, LOC)? If so, how can this be done since their merge efforts may be scattered over several merges to trunk until they are done? Especially when they take in others' changes from the trunk into their working directory, too? Can this be done? Once last question, do you employ a nightly build to ensure that all is well with the days' worth of merges? Thank you for your reply, DC __________________________________ Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com