Actually, I think this often works better than people expect.

We set a flag that marks a given codeline as "frozen", which causes our wrappers to issue a reminder that says, e.g.:

| b4p4: Note: | | Your submit includes changes to the following frozen codeline(es): | | branch name state owner alias(es) | -------------------- -------- ---------- ------------------------- | ontap:Rbecks frozen taiello becks.6 | | Local policy states that all changes to frozen codelines must be | approved by the codeline owner (or their delegate). If you *don't* | have such approval, please Control-C out of this submit now, (You'll | need to do it twice!) and seek it before continuing. | | (If you *do* have such approval, press Return to continue)

We have hundreds of developers and dozens of "active" ("open" or "frozen" codelines), and I have never heard anyone complain about somebody disregarding the reminder; nobody has ever suggested that we enable perforce access controls to deal with this.

After all, if somebody *were* to abuse this, they'd leave big tracks.

(We also have another state "obsolete", that basically precludes submits on that codeline entirely).

Our protections table currently is:

| Protections: | write user * * //... | super user p4 * //... | super user rmg * //...

I don't spend a whole lot of time maintaining it.

Now, I'm not claiming that this is for everybody; we may in fact start to actually use protections more at some point in the future. But I must admit that I hear more discussion about how to set up Perforce access controls than I'd expect.