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. The cache is a file in the metadata area of the depot. Access to the depot area allowing locking files to be set up should be limited - perhaps to team leaders, etc. This version is for an NT server and sets all path names to lower case for comparison. To use with a unix server, remove the "lc" function calls. 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%"
|#2||310||paul_goffin||Added more usage notes.|
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
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.