I agree with 98% of what's here, but want to add my $0.02.

The most important thing that Diane has said is 100% correct: Branches may be "cheap" in terms of how Perforce deals with them, but they're not in terms of people having to deal with them... I think that Perforce branches are terrific, but it's important to pay attention to the amount of human-time ("staff-time") to deal with them, and minimize the amount of time spent doing integration work.

Now, using a (pathname, changenumber) combination is sufficient to represent a release. Always. (I disagree with Diane on this part.) But it's important to compare apples to apples, in this discussion: if you have a "release branch" into which you keep all code destined for the release, and start that branch prior to releasing the product, then (pathname, changenumber) will be the immutable designation of the release. However, there will be integrations needed in the minutes/days prior to the release - to include bug fixes.

But Diane's point remains a good one: it's important to realize that there are folks dealing with the development of the software who might not be as SCM-savvy as we are, and for whom we need to minimize the number of steps.

Here's one thing I do, in a branch-centric model, to minimize the hassles for a developer. (Again, it's AN approach, not THE approach. Diane's rule, above, is certainly one to guide any process you implement.)

One thing I've done in the past is the following, assuming that there are five scheduled handoffs to QA for a release: handoff #1: build out of the normal development codeline, identified as "//depot/devline/... at 12367". handoff #2: build out of normal development codeline, identified as "//depot/devline/... at 12563". handoff #3: by now, people want to start checking in their work for the next release. So I'll branch 'devline' to make //depot/2.3/... (since this is for release 2.3) and the handoff is identified as "//depot/2.3/... at 12832". --------- As of this point, //depot/2.3/... is marked (using 'p4 protect') as --------- writable by the build/release guy and no one else. All subsequent --------- changes are made to //depot/devline and integrated by hand by --------- the build/release guy who inspects - eyeballing every change - --------- the change for stability and necessity. handoff #4: Built out of //depot/2.3/..., the only changes to this branch are those hand-integrated by the build-guy as above. This is identified as "//depot/2.3/... at 12932". handoff #5: same as #4. Of course, any bug-fix to a file in 'devline' that can't be made because release 2.4 features have changed the file "too much" must be made directly in //depot/2.3/... now, with the build-guy directly involved.

By doing this, a developer continues to work in "devline" for all his 2.3 and 2.4 work, no codelines are ever "frozen" to prevent development from checking in work, and everything remains well-defined.

Of course, this assumes that you know in advance that there will be multiple handoffs to QA. The truth is, you DO know that, even if the people officially scheduling the release (marketing and managers) don't.

-Jeff Bowles San Francisco

At 12:33 PM 4/24/2001 -0700, Diane Holt wrote: