Lock Branch. Perl triggers to allow non-superusers to lock branches. They do this by setting up lists of depot paths in simple text files (one path per line, a "#" anwhere in the line makes THE ENTIRE LINE a comment) in a "well known" directory. (defaults to "//depot/locks") The lockbranch.pl trigger checks submissions against a cached list of paths derrived from the //depot/locks files. If any path matches, the submission is rejected. lockbranch.pl detects its cache is stale by relying on a counter set by the lockcachestale.pl trigger. Usage: set up the two triggers as follows lockareas //depot/... "c:/perl/bin/perl c://Triggers/lockbranch.pl %changelist% %serverport% %client%" lockareas -//depot/locks/... "" cachelock //depot/locks/... "c:/perl/bin/perl C:/Triggers/lockcachestale.pl %changelist% %serverport%"
# | Change | User | Description | Committed | |
---|---|---|---|---|---|
#2 | 310 | paul_goffin | Added more usage notes. | ||
#1 | 309 | paul_goffin |
lockbranch trigger (and companion lockcachestale) Triggers to allow ordinary (non-super) users to lock branches of the depot against submissions without needing access to `p4 protect`. Users just add text files to a `well-known` place, (say //depot/locks/*) these files contain lists of depot paths that submissions should be refused from. I suggest each project leader is given permission to set up a single file - say a file named with their own name (or user name) and all other users are prevented from changing files in the //depot/locks area - that way you should avoid unintentional denial-of-service events! Obviously using these locks is slower than the "protect" system, but it is useful when the admin is too busy to add the lock. |