The concept of a codeline is formalized. Each codeline may have its own regression and default view. The creation of workspaces (a.k.a. clients) and codelines, as well as integration between codelines, is automated.

A4 does not supplant the direct use of Perforce — it merely streamlines some operations that are otherwise complicated and error-prone. Clients and branches created with A4 are specializations of Perforce clients and branches, respectively, that can be accessed either through A4 or through ordinary Perforce operations.

Changes that might otherwise be stranded because they cannot be successfully submitted may be projected onto another workspace — most likely a workspace based on a different codeline.

If the view file is missing, then the view is similar to that of the parent codeline, but points to a different tree in the depot, such that workspaces look and feel much like workspaces based on the parent codeline.

The scope of codeline integration is controlled via an alternate client view that is also defined by a workspace file, and the branch view itself never changes. The problem of concurrent codeline branch spec editors wiping out each other's changes is thereby avoided.

New workspaces can be cloned from a reference build, such that they can be built incrementally, potentially saving hours or even days of build time.

.p4env files are also created automatically, so that the correct client is always selected. To support directory sensitive Perforce settings (e.g. P4DIFF), simply create a .p4props file, and a corresponding .p4env file that specifies the present client will be generated.

If you use Perforce passwords (and you should, because otherwise your account is wide open to anyone on the network) just create a "~/.p4passwd" file. Then your .p4env files will be unreadable by others, and will set your password. (Never set P4PASSWD from your environment or on the command line, because then it's visible to other users via ps(1) on many systems.)

Because the target directory is always the same node (as long as you stay in the same workspace), it is usually legitimate to use such a path where an absolute path would otherwise be required, such as the value of a PREFIX configuration variable in an install script.

Most of these paradigms dictate that near-production test occurs early and often — as often as several times per day. By preventing malfunctional changes from entering prominent codelines, without requiring costly code freezes, A4 ensures that parallel development activities can continue uninterrupted. Productivity can therefore increase substantially.