[p4] Branch deprecation procedure?

[Stephen Vance]

Your spec management solutions seem reasonable.

As for how to actually protect it, it depends on what you want to achieve.

If you trust your developers or don't mind the possibility of additional 
checkins, (1) is appropriate.
Option (2) is good if you still want it visible as a reference.
Don't bother with option (3). It adds unnecessary rev records and still 
won't hide or protect the branch. Security by obscurity never works well.
There are a couple of variations on option (2) that you can take.
Of course, the normal one is to exclude it from a higher scope if 
necessary and redefine it as "read".
If you want to hide it, you can also make it readable by a group that no 
one belongs to. This won't hide it from super, but it also gives you the 
flexibility to add people to the group and change the permissions for 
that group easily if the branch is revived.
If you want to hide it from everyone, including "super," put the entry 
below the super line. It has always been wise to leave a "super" back 
door at the end of the table if you do this, perhaps for a particular 
user rather than your admin group, but the latest versions of Perforce 
require this now.

As for the question about whether to explicitly include or explicitly 
exclude, I would judge that by your predominant case and your overall 
security philosophy. Right now that would argue in favor of just 
excluding the ones that are obsolete.

Steve

Marc Wensauer wrote:
> We're about to deprecate our first branch (i.e.: it's no longer needed),
> and I'd like to know what procedures you follow when deprecating a
> branch.
>
> So far, I think the following are in order:
> * Delete the branch spec (we can always recover it from the spec depot)
> * Delete the corresponding template client workspace
> * Delete the corresponding user's client workspaces (perhaps a little
> controversial?)
>
> Now as far as the material on the branch itself, I see these options
> ahead of me:
> 1) Do nothing -- leave the branch there.
> 2) Add an entry to the protections table to mark it read-only
> 3) Delete (p4 delete) the branch
>
> I don't like #1 because it leaves a folder around that over time, will
> add to the noise of obsoleted branch folders when browsing the depot.
>
> Option #2 sounds interesting as it will essentially hide it, but I worry
> about doing this for every branch that ends up deprecated -- if the
> protections table grows large, it can negatively impact performance.
>
> Option #3 sounds somewhat drastic, but still recoverable.
>
> I suppose a variant of option #2 is to structure the protections table
> to only allow write-access to the active branches, leaving by default
> anything else there read-only.
>
> I'd appreciate hearing how you deal with obsoleted branches.  Thanks for
> your advice,
> -Marc
> _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user
>
>   

-- 
Stephen Vance
www.vance.com