Group Ownership of Streams
The topic of code line management and policy makes for some lively discussions. If you ask 10 engineers their opinion, you'll get at least 12 answers.
Not every team is going to pick the same strategy. Some want restrictive policies. Some want open and free policies. It's even possible that some want the policy to change depending on the timing of the development-release cycle.
We definitely get it. We think choices are great; getting locked into a choice less so. That's why we're listening and continuing to add tools and features to support your choices.
Perforce 2013.1 now supports Group Ownership of Streams.
This makes it possible for any user in a group to manage a Stream. This is a big deal for teams that structure their strategy around multiple owners. Any user that's part of a group can dynamically and freely make changes to the Stream spec. Good riddance to bottlenecks from waiting for someone else to get around to making the change.
Anyone in the group can now change the configuration of the Stream to control which files go into it, if the files are read only or writeable, who gets to make changes to the files, and the flow of change to and from the Stream.
It's a piece of cake to use this feature. All you have to do is put the group name in the Stream spec owner field.
>p4 stream -o //streams/dev Stream: //streams/dev Owner: DevGroup Options: ownersubmit unlocked toparent fromparent ...
To up the ante, here's an example of how you can combine the new group owner feature and the ownersubmit Stream Options feature to get finer grained control of code line protections without mucking with the venerable protections table.
If you only want the users in the DevGroup to be able to submit to the Stream, simply set the ownersubmit Stream Option. Since the ownersubmit option restricts check-ins to the owner of the Stream, and the owner is now a Group, only users in the DevGroup group can submit changes.
Yep, you read that right. It duly serves as a lightweight protections scheme for non Admin privileged users. This puts the power right in the hands of the code line owners without compromising security for the entire system.
Here's a little caveat: If you have a user and a group with the same name, but the user is not part of the group, then both the user and the group will have Stream ownership.
Go ahead, grab a copy of 2013.1 and give it a try!