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, >>> Team sizes are 5 or less, and usually size of 1, 2. Unless the functionality of your project is _very_ poorly partitioned across the files, teams that small will very seldom ever be working on the SAME file as the SAME time, so there will very seldom be a need to merge anything. Therefore, your elaborate branching strategy is not needed but will definitely be in the way. >>> If developers modify different files, is a merge from a developer branch to integration branch all that hard? If developers are working on different files, then there is no need for _any_ merge, hard or easy. >>> 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)? DIFFs, yes. As for metrics, that depends on what metric tools you are using. Everything in CVS (e.g., checkout or DIFF) is based on a "revision" of a file. The revision can be a revision number as maintained by CVS (e.g., 1.23) or it can be a tag (aka label), which is a string you can attach to a revision of one or more files (e.g., RELEASE_20041105). If you do not specify a revision to use, then the HEAD (i.e., the most recent) revision is used. >>> In your example, the Test dept would have 2 different piles of code, both from tags TEST_RELEASE! This all depends on what your software process requires. If you test people wake up on a whole new world each time the project manager says, "It's ready for testing," :-) then a single TEST_RELEASE tag that is moved with each test-ready release would work. If you test people want to keep a history of what they have tested (which isn't a bad idea), then the project manager could either use a unique tag such as TEST_RELEASE_xxx where "xxx" is your internal release name. Or, the manager might attach a more generic RELEASE_CANDIDATE_xxx_n tag, which both the developers and the test people would use. These unique tags would never move from their initially assigned revisions. If RELEASE_CANDIDATE_xxx_1 needs more work, then later there will be a RELEASE_CANDIDATE_xxx_2 tag for the test people to work on. The exactly name of the tag and the decision as to whether one name moves with time or is stable is a matter for your software process to decide. The only _real_ point I was trying to make is that the test people are told to go test a _specific_ tag rather than assuming they will be testing the HEAD revision of each file. Choose your tags names to fit you situation, just make sure you always test a specified tag. >>> The developer gets a version of code in their working directory, makes changes, tests it, and then merges it back to the trunk. Hmmmmm. We may be running afoul of nomenclature here. One common workflow in CVS is for a developer to start by checking out the whole project tree onto his or her workstation. The developer makes changes as needed, and tests them against the code in the tree on the workstation. During this time, the developer should periodically "update" his tree (e.g., first thing in the morning), so that he will "see" any changes made by others to other files, but which may effect the local code changes. (Remember, when the developer is compiling the project to test the changes, all project files are being compiled, so the developer needs to keep uptodate with everyone else's contributions.) When the developer thinks the changes are ready, he first does a DIFF to remind him of all the changes he's made to each file. He can leave the DIFF up while he "commits" the changes he has made in his local tree to the master CVS repository (which it will be seen by _all_ developers). The commit operation (which is apparently what you meant when you said "merge"), allows the developer to provide text describing the changes. (That why it's useful to have the DIFF up in a different window while doing the commit.) The CVS commit operation is fairly smart. The file the developer is committing may have been changed in the meantime by some other developer. If the developer's changes are not in the same area of the file as the changes made by the other developer (e.g., on different lines), the commit operation will quietly merge the developer's changes into the modified file already in the repository--and all is well. However, if commit finds that the developer's changes conflict with some of the changes made to the repository by the other developer, then it raises a red flag, forcing the developer doing the commit to manually merge his changes into what in currently in the repository. Therefore, only truly conflicting changes by two different developers trigger a merge. Given the fact that you typically have less than 5 developers working on the same set of files, there should be very few cases when a manual merge by the developers is ever required. So forget branches. Your developers will thank you for it. >>> do you employ a nightly build to ensure that all is well with the days' worth of merges? Yes. Periodically builds, usually nightly, are one of the best ways of avoiding nasty surprises down the road. Of course, the test build should be followed by running a set of regression tests to make sure none of the existing functionality has "unexpectedly" gone away. :-) Merrill