目前在我创建发布分支之后,但是当我们在发布之前有一段时间时,我有时会打开整个分支进行编辑,然后锁定所有文件,以防止任何人在发布分支的“代码冻结”期间修改任何内容.
有没有更好的办法?以我目前的方式这样做似乎可能是对锁定功能的错误使用,有没有更好的方法来阻止某人在不使用分支的情况下签入代码。我虽然是 P4 保护,但我不是这个 perforce 实例的管理员,而且处理可能有 100 行的保护文件也会变得很麻烦。
有任何想法吗?
目前在我创建发布分支之后,但是当我们在发布之前有一段时间时,我有时会打开整个分支进行编辑,然后锁定所有文件,以防止任何人在发布分支的“代码冻结”期间修改任何内容.
有没有更好的办法?以我目前的方式这样做似乎可能是对锁定功能的错误使用,有没有更好的方法来阻止某人在不使用分支的情况下签入代码。我虽然是 P4 保护,但我不是这个 perforce 实例的管理员,而且处理可能有 100 行的保护文件也会变得很麻烦。
有任何想法吗?
作为构建工程师,我一直在这样做。我使用“p4保护”将每个人对树的访问限制为只读:
super group everyone * -//depot/project/branch/...
read group everyone * //depot/project/branch/...
super user me * //depot/project/branch/...
第一行关闭所有用户对分支的所有权限(假设组 'everyone' 已正确定义。)
第二行重新建立每个人的读取权限。
最后一行重新建立了对我的所有权限。
The way to do this in modern Perforce is to use streams -- named branches that update in place on your local system, and can have permissions applied to encourage you to do the right thing when merging and copying between streams.
You can optionally restrict a stream so only the stream owner can check in (and you can lock the stream so no one but the owner can edit its properties). See http://www.perforce.com/perforce/doc.current/manuals/p4guide/chapter.codelines.html#codelines.streams
p4 protect 绝对是更好的选择——它就是为此而存在的。我强烈建议您将所有用户分组,并且只在保护表中使用组 - 更易于管理。
You can protect at any level of granularity you like, so is not unwieldy. Note also that the 2008.1 server release has a new protect feature that allows you to specify what you can do in a slightly different way. Change note:
#152278 **
'p4 protect' now allows specification of permission 'rights'.
Previously, 'p4 protect' only allowed using permission levels
which include the specified access (ie 'read') and also all
of its lesser permissions (ie 'read' = 'read' + 'list').
Permission rights make it possible to deny individual rights
without having to re-grant lesser rights. The new
permission rights are '=read', '=branch', '=open',
and '=write'. This functionality was previously undocumented,
and is now fully supported for 2008.1
If you really have an issue with having to be an admin to lock & unlock this, then you should take a look at the "group owner" feature introduced in 2007.3. This will let a non-super user to be able to add & remove people from a group. So combine that with the protections table. I.e. get site admin to set up the protections table, and restrict rights to a group named "Rel 1.0 Authorised", and make you the group owner. You can then add and remove users (or subgroups) from that group to control access.
The trigger option is a possibility, but you still need to be an admin to set up the trigger in the first place. You could also affect performance of all submissions, which is something to look out for. But the main issue with triggers is that you would be using them to emulate a built in feature designed for that purpose - i.e. protections table. And, if you wanted to be safe, you would still need to find some way of preventing anyone else modifying the reference file. It just seems like a lot of work to emulate an existing feature.
As a slight addition to one of the other answers. First set up a group "everyone" which has all users in it. Then add this to p4 protect
write group everyone * -//depot/project/1.0/...
read group everyone * //depot/project/1.0/...
write group 1.0 * //depot/project/1.0/...
This will allow you to create a group "1.0" into which you can add any users who are allowed write access.
If you are using server 2008.1 you can do this.
=write group everyone * -//depot/project/1.0/...
write group 1.0 * //depot/project/1.0/...
The first line removes only the write access ( not read and list ) from the group everyone.
正如其他答案中所解释的,P4 保护可能是大多数人的正确答案。
但是在我的组织中,我不能成为管理员,因此这样做的方法是在 perforce 中使用一个触发脚本,该脚本读取非管理员具有写入权限的文本文件并检查分支是否出现在列表中。这样就不需要像 p4 Protect 这样的管理员访问权限。