[p4] Protection Strategies
jgrills at junctionpoint.com
Wed Jul 19 09:36:26 PDT 2006
Since perforce maintains all the history, unless you've given users super
access so that they can obliterate, you can always back out changes that
people have made - in fact, there are several scripts in the public depot to
do exactly that (I even have mine there). So you generally don't need to
worry about someone damaging your repository.
I've found that using your version control software to enforce company
policies (like formatting rules, code reviews, etc) just breeds discontent
among the developers. I've worked in environments where access is limited
to exactly what people need, and also where everything is writable. From
what I've seen, limiting access in perforce has similar consequences, though
not as severe, as using perforce triggers to enforce policies that impede
rapid workflow. So, I would personally avoid it unless you have some
compelling reason. How valuable is your source code without the people that
can understand it, maintain it, and enhance it? Chances are, not very,
although that's not always the case.
From: perforce-user-bounces at perforce.com
[mailto:perforce-user-bounces at perforce.com] On Behalf Of Mike Jameson
Sent: Tuesday, July 18, 2006 2:54 PM
To: perforce-user at perforce.com
Subject: [p4] Protection Strategies
We've currently setup our protections to grant developers write access to
the projects they're assigned to, and read access to the rest (with a few
exceptions). This allows developers to see what else is happening around
them, but it increases the likelihood a disgruntled developer could walk off
with the majority of our source.
How have others setup their protections?
Do you Yahoo!?
Get on board. You're invited to try the new Yahoo! Mail Beta.
perforce-user mailing list - perforce-user at perforce.com
More information about the perforce-user