Change 4662
Add the first release of my Perforce command line client for Unix
sysadmins. On a Unix box, some of the files you really want under
version control need to be protected. P4 uses the user's umask
to control the permissions on the files it manages but when you're
managing a unix box these permissions can vary on a per-file basis
and that makes it tricky to manage unix boxes properly with
Perforce.
Enter P4U. It uses the 2004.2 server's ability to store per-revision
attributes to store a permission-mask for each file that requires
custom handling. The bits in the mask are removed from the
permissions of the relevant files when normal Perforce commands
are executed using 'p4u' instead of 'p4'.
i.e.
p4u add /etc/shadow
p4u attribute -n unixMask -v 077 /etc/shadow
p4u submit
This will cause /etc/shadow to have the mode you would hope for (0400).
The mode will be restricted whenever you:
p4u submit
p4u edit
p4u revert
p4u sync
Currently that's it.
sysadmins. On a Unix box, some of the files you really want under
version control need to be protected. P4 uses the user's umask
to control the permissions on the files it manages but when you're
managing a unix box these permissions can vary on a per-file basis
and that makes it tricky to manage unix boxes properly with
Perforce.
Enter P4U. It uses the 2004.2 server's ability to store per-revision
attributes to store a permission-mask for each file that requires
custom handling. The bits in the mask are removed from the
permissions of the relevant files when normal Perforce commands
are executed using 'p4u' instead of 'p4'.
i.e.
p4u add /etc/shadow
p4u attribute -n unixMask -v 077 /etc/shadow
p4u submit
This will cause /etc/shadow to have the mode you would hope for (0400).
The mode will be restricted whenever you:
p4u submit
p4u edit
p4u revert
p4u sync
Currently that's it.
Tip: Use n and p to cycle through the changes.