[p4] Branch deprecation procedure?

[Frank Compagner]

Yes, but make sure you understand the performance impact of
exclusionary mappings. Some time ago I decided to hide about 20
obsolete branches with lines in the protect table like this:

write  group  *  *  -//depot/oldbranch1/...

This brought the server to it's knees. Cpu usage was 100% all the
time, and even the simplest queries would take minutes to complete.
It might not be too bad if it's just one or two exclusionary lines,
or if the branches aren't located so close to the depot root. But be
careful.

I'm now using only inclusionary mappings in the protect table listing
all active branches (the admin account still has access to
everything). This has no performance impact at all, as far as I can see.
This does mean that creating a new branch requires admin access, but we
don't create enough new branches to make that a real problem. If you
have many people creating branches all the time, that might be an issue,
though.

----------------------------------------------------------------
Frank Compagner                                  Guerrilla Games

SV> Your spec management solutions seem reasonable.

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

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

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

SV> Steve

SV> 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
>>
>>