[p4] Automatic lock in checkout (edit)

[Chuck Karish]

On 5/14/07, Javier Crespo <javier.crespo at altana.es> wrote:
> We want always have a stable-line that we can deliver at any moment,
> (for example now)
>
> We are thinking about to have only 2 brach, one for "deploy-line" and
> another for "stable-line".
> We want to make the changes in the "deploy-line".
> We want to compile with "stable-line" plus some fixes. If the build pass
> the test (of a human testing team), then we want to "integrate" that
> fixes into the "stable-line".
> In order to reduce risk (of dirty files), we want to lock the files
> (with the fix), and unlook it only when the file will be integrated.

I've used this pattern successfully several times at different companies.

The development code line is managed so it's in a close-to-releasable
state at all times, checked by continuous-build machines.

When a release is needed a full integration is done from the development
code line to the release branch, at a changelist at which the development
code line is feature complete and at which the continuous build shows that
it's healthy.

Any problems noted on the release branch are fixed by integrating
individual changes from the development code line.

Only a few people have access to the release branch.  Changes are merged
there only after the release team approves them.  No locking is needed.

-- 
Chuck Karish   karish at well.com   (415) 317-0182