[p4] Exclusive locking binary files

Robert Cowham robert at vaccaperna.co.uk
Fri Feb 8 14:35:52 PST 2008


A couple of options:

1. Make sure users have the "poll server for updates" option set to a small
value (small number of minutes). This will force refresh of status and thus
trigger other error messages.

2. Do something like journal tailing to detect edits of files (no trigger
available) and email errant users. 

Neither option perfect, but could help improve things if it is such a
problem.

Robert

> -----Original Message-----
> From: perforce-user-bounces at perforce.com 
> [mailto:perforce-user-bounces at perforce.com] On Behalf Of Craig James
> Sent: 07 February 2008 22:56
> To: perforce-user at perforce.com
> Subject: [p4] Exclusive locking binary files
> 
> Hi everyone,
> 
>  
> 
> I'm hitting a problem with locking that comes at a different 
> angle to the issue described in this thread
> http://maillist.perforce.com/pipermail/perforce-user/2007-Sept
ember/0224
> 30.html.
> 
>  
> 
> We are using 2007.2 and the basic problem is... 
> 
>  
> 
> 1.       Both users sync and keep P4Win open
> 
> 2.       User 1 checks out a binary file using P4Win, changes 
> and checks
> it in
> 
> 3.       User 2 now checks out the same file using P4Win (without F5
> refreshing perforce win client), changes file and goes to 
> check it in - but finds the file has been changed and cannot 
> merge their own changes in
> 
>  
> 
> This is quite a problem for us as it doesn't enforce a 
> sequential user workflow on binary files (such as 
> bitmap/photoshop images or 3d models).
> Falling back on resolving differences at check-in is just not 
> an option.
> 
>  
> 
> If User 2 refreshes P4Win before checking out (with F5), 
> perforce will ask the user if they wish to edit current or 
> sync before edit.  Relying on users to do this is problematic.
> 
>  
> 
> There are two pieces of design here that do not suit what we 
> are looking
> for:



More information about the perforce-user mailing list