(I've copied Chris Seiwald in on this as he wrote the paper....)

I wonder if anyone can help me clarify my thoughts on a "branch on release" strategy with Perforce?

Here goes.....

It (now) seems to me that the natural way to indicate a "release" with Perforce is to use branching. Thus:

//depot/project_1/main/...

gets branched to, say:

//depot/project_1/release1/...

when release 1 is ?

Let me explain my question a little. It seems to me that there are two possible times that the branch should take place.

Either the branch should be formed when //depot/project_1/main/... is at the state known to be "release1" and so the ONLY revision of all files in the //depot/project_1/release1/... are the released code; (I'll call this method 1)

or,

the branch should be formed as soon as it is known there will be a release1. Then the LAST (ie head) revision will be the released code. (I'll call this method 2).

OK then,

Method 1 has the advantage that all development proceeds along the main line (and continues seamlessly after release). In addition, if "$Id$" is used, no files - except those actually in the release - have "release1" in their path.

Method 2 makes the main line redundant as development towards "release1" continues in "release1" until complete. Also, development can continue in, say, the "release2" branch during the testing of "release1" without _having_ to integrate changes into "release2". (With method 1, changes in the mainline would be changes in release2 as well as release1.)

but,

Method 2 identifies ($Id$) files as being part of release1 when they may not (eventually) be.

On balance, I prefer method 1. But:

What happens when I need "release1.1"? With method 2, it's easy. I just branch "release1" into "release1.1", knowing that when release1.1 is complete it will be the head revision.

But with method 1, I now seem to need to develop in "//depot/project/release1/..." and then branch into "//depot/project/release1.1/..." when it's complete.

This gives rise to the potential problem that anyone doing a "p4 sync //depot/project/release1/..." will not get "release1"; they'll get a development version of "release1.1".

So, it seems I need a refinement to Method 1:

Instead of branching to "//depot/project1/release1/..." I branch to "//depot/project1/release1/main/..." AND to "//depot/project1/release1/.0/...".

That way, there's a "main" for development of "1.1", if it's ever required AND release1 is preserved as the head (and only) revision of "release1/.0".

Well, if you've managed to stick with me so far, I hope you agree that this is getting a bit complicated - and I don't like complication.

Hence my call for advice. Anyone got any?

Paul.