[p4] exclusive checkout across branches

[Jeff Grills]

I wanted this sort of feature for a while for some files that can not be
merged, but realized it was insufficient to solve the problem I had hoped it
would solve, and I suspect the same may be true for the majority of people
in this scenario.  If the file is checked out in one branch, modified, and
then submitted, then the file should not be modified in another branch until
all the changes have been integrated into that branch.  Since the file has
already been submitted in the first branch, a user would be able to modify
the file in a second branch because the file is no longer checked out in any
branch to fail any sort of exclusive checkout test.  Eventually, the two
separate modifications will be integrated to the same branch with no way to
merge the changes to resolve the conflict.  You really need to check for any
unintegrated changes in any of the other branches before allowing the user
to check the file out for edit - that's not something you'll be able to do
with the protection table, so you'd have to implement it in a trigger, and
that trigger will have to understand your branching structure in order to
correctly check all the other branches.  I suspect this would be a
reasonable amount of perforce scripting work to accomplish the feat.

j

> -----Original Message-----
> From: perforce-user-bounces at perforce.com 
> [mailto:perforce-user-bounces at perforce.com] On Behalf Of 
> Jamie.Echlin at barclayscapital.com
> Sent: Monday, January 08, 2007 5:32 AM
> To: perforce-user at perforce.com
> Subject: [p4] exclusive checkout across branches
> 
> Sorry for all the traffic, trying to bring myself up to speed.
> 
> A group has certain files that should be "exclusively lock", 
> including across branches. This is particular named files, 
> not all having a certain extension or anything so simple. 
> 
> I guess an implementation option is using +l in the typemap, 
> and protections file to make read-only everywhere except the 
> main branch. I don't want to do this because I'm wary of 
> adding many rows to protections, also I want something 
> whereby they can make changes to this list without having to be admin.
> 
> I guess many people have this sort of requirement, any suggestions?
> 
> My preferred option is a trigger which would read a 
> project-supplied file containing list of "special access 
> rules", ie depot path patterns and rules. However the trigger 
> would only fire on submitting the changelist, not when they 
> make the checkout. I prefer a trigger because it allows us to 
> provide some explanation of the failure - eg please make 
> these changes in this branch..., as opposed to using the 
> permissions table which would just say "access denied"...
> 
> Thanks in advance,
> jamie
> 
> --------------------------------------------------------------
> ----------
> For more information about Barclays Capital, please visit our 
> web site at http://www.barcap.com.
> 
> Internet communications are not secure and therefore the 
> Barclays Group does not accept legal responsibility for the 
> contents of this message.  Although the Barclays Group 
> operates anti-virus programmes, it does not accept 
> responsibility for any damage whatsoever that is caused by 
> viruses being passed.  Any views or opinions presented are 
> solely those of the author and do not necessarily represent 
> those of the Barclays Group.  Replies to this email may be 
> monitored by the Barclays Group for operational or business reasons.
> --------------------------------------------------------------
> ----------