[p4] Giving each user a private sandbox

[Weintraub, David]

My problem isn't really Tom messing with Bob's stuff. (Let them duke it
out mano-a-mano during lunch when we can all watch.) It's Tom and Bob
deciding they want a few extra "private folders", and there really isn't
anything I can do to stop them. When a developer leaves, I want to
*EASILY* find out what stuff is theirs. It's one of the reasons why I
make sure all views begin with the user's ID. If developers are free to
create extra folders in //depot/Private, it would be much harder to
figure out who owns what.
 
In Subversion, we used triggers (what Subversion called "hooks") to
implement what Perforce does in its protection tables. I like the idea
that in Perforce protections are built in. However, instead of using the
default "security hook" that came in Subversion, I wrote my own that
added a few features missing from the standard hook (group permissions,
tag/label protection and locking where you could create a tag, but not
modify it, etc.). One of the features was the ability to use the string
%USER% to refer to the individual user's ID. This allowed me to
implement the private folder strategy.
 
I could do something similar in Perforce via triggers, and that might be
the way to go. However, it would mean that part of the protection scheme
for Perforce is implemented in one location, and the rest in a second
location (and in a very non-standard way too).


________________________________

	From: Shawn Hladky [mailto:p4shawn at gmail.com] 
	Sent: Wednesday, May 10, 2006 7:14 PM
	To: Weintraub, David
	Cc: perforce-user at perforce.com
	Subject: Re: [p4] Giving each user a private sandbox
	
	

	Do you really need that level of control?  We have user depot
setup with folders for each user.  Everyone has full read/write on the
entire user depot, and in over 2 years we've had no incidence of abuse. 

	 

	The way I see it, if Tom messes with Bob's stuff, why not let
Tom and Bob hash it out mano a mano.  There's no way Tom can do it w/o
full history, and it's easy for Bob un-do anything Tom does.  And it's
quite likely that they want to share the directory intentionally. 

	 

	At least that's the way it works here... a company w/ 100 users
in a couple geographic locations.  With thousands of users and dozens of
offices, it may get more complicated. 



	 
	On 5/10/06, Weintraub, David
<david.weintraub at bofasecurities.com> wrote: 

		Is there someway to setup Perforce's protection tables
to do something
		like this:
		
		       write user %USER% * //depot/Private/%USER%/... 
		
		So, that "bob" had permission in //depot/Private/bob/...
and "tom" had
		write permission in //depot/Private/tom/..., etc.
		
		I would like to setup separate sandboxes for each user,
but I really 
		don't want to add 90 plus lines in my Perforce
protection table to do
		this.
		
		My biggest fear isn't Bob messing around with Tom's
private directory,
		it's Bob, Tom, and everyone else deciding they could use
more than one 
		private directory, so I end up with thousands of
directories under
		//depot/Private instead of one for each user. I'd be
satisfied with
		users being able to write to //depot/Private/*/..., but
not be able to
		create another directory under //depot/Private if it
previously didn't 
		exist.
		
		Has anyone done anything like this?
		
		--
		David Weintraub
		david.weintraub at bankofamerica.com
		david.weintraub at bofasecurities.com
		_______________________________________________
		perforce-user mailing list  -
perforce-user at perforce.com
	
http://maillist.perforce.com/mailman/listinfo/perforce-user