[p4] Concept of file ownership

[Tony Sweeney]

steve at vance.com wrote:
> See below.
>
> Steve
>
> Original Message:
> -----------------
> From: Calman, Kevin Kevin.Calman at acs-inc.com
> Date: 	Tue, 12 Aug 2008 09:35:36 -0500
> To: perforce-user at perforce.com
> Subject: Re: [p4] Concept of file ownership
>
>
> On Monday, August 11, 2008, Stephen Vance wrote,
>
> | By 'owner' I assume you mean managerial or administrative 
> | responsibility. I'd be interested to hear what abilities and 
> | responsibilities you associate with this 'ownership'.
> 	I am thinking more like team or design lead responsibility. In the
> context of peer code review, the person who would be required reviewer or
> moderator. In the context of problem determination, the "go-to-guy" for
> treating emergency production issues. In the context of future design
> activity, the person who "owns" the architecture of the module of which any
> given file is a part.
>   
Why not just use the existing review mechanism?  You don't have to be 
running a review daemon to benefit from it.  If Alice is the code lead 
for //depot/libcompat, say, she can add a 'Reviews:' field to her user 
record as follows:

Reviews:
    //depot/compatlib/...

The command 'p4 reviews <filename(s)>' can be used to see who is set up 
to review <filename(s)>.  If I want to see all reviewers of everything I 
have opened:

sweeney at golem:~/src$ p4 opened | sed -e 's/#.*$//' | p4 -x - reviews | 
sort | uniq
perforce <perforce at golem> (perforce)
sweeney <sweeney at golem> (sweeney)
sweeney at golem:~/src$

Etc.

Tony.
> == Dan's feedback plays well with this. Establish a group with write
> permission to that area. By convention establish that the first person in
> the group list is the group leader to handle your ownership metadata. Make
> that person an 'admin' over that directory tree in the protection table.
> Give everyone outside of that group read or no permissions. Use the undoc
> '=branch' as an exclusionary protection to prevent people from making
> unauthorized copies of the tree.
>
> | As for adding an explicit marker of ownership, you could add 
> | an attribute (undoc but used by Perforce for production 
> | functionality) on the first revision indicating the owner. 
> 	This is what I was looking for, I'll check it out.
>
> == For the group as I indicate above will be more efficient storage-wise
> and will not require undoc functionality.
>
> | I'm also curious which systems you've seen implement 
> | ownership. Although some I've seen use the term 'owner', they 
> | are pretty much equivalent to Perforce's use of 'user' except 
> | where they use file system permissions to do what Perforce 
> | does with the protection table. Out of the box, I can't think 
> | of one that has both concepts.
> 	One specifically that I am thinking of would be IBM's
> Orbit/CMVC/TeamConnection product, where every file had permissions similar
> to a Unix file system: a defined owner and group.
>
> ==Interesting. I haven't played with that one. ClearCase does something
> similar but I considered it a weak form of ownership.
>
> --------------------------------------------------------------------
> mail2web - Check your email from the web at
> http://link.mail2web.com/mail2web
>
>
> _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user
>
>
>