[p4] exclusive checkout across branches

[Jamie.Echlin@barclayscapital.com]

That's true but that's a tougher problem than the one I am trying to
solve. I would just ensure that checkouts can only be done on one
particular branch, so this would not be an issue. My subject line was
misleading in that respect, so apologies.

> -----Original Message-----
> From: Jeff Grills [mailto:jgrills at junctionpoint.com] 
> Sent: 08 January 2007 17:25
> To: Echlin, Jamie: IT (LDN); perforce-user at perforce.com
> Subject: RE: [p4] exclusive checkout across branches
> 
> 
> 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.
> > --------------------------------------------------------------
> > ----------
> 
>