[p4] Exclusive locking binary files

Craig James Craig.James at thq.com
Thu Feb 7 19:06:31 PST 2008


I forgot to state that the test files had the +l exclusive open option
enabled.

Cj

-----Original Message-----
From: perforce-user-bounces at perforce.com
[mailto:perforce-user-bounces at perforce.com] On Behalf Of Craig James
Sent: Friday, 8 February 2008 8:56 AM
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-September/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:

 

1.       P4Win doesn't refresh the file status before open-for-edit.

2.       There is no server-side feature to prevent clients from
opening-for-edit a binary file at an earlier revision.

 

The first is a problem for us if we only work through P4Win and the
second is a problem also for any p4 command line open-for-edits.

 

Ideally we'd be looking for either/or/both:

1.       Option in P4Win to force refresh of file status before
opening-for-edit.  I'd gather there is a performance reason this is
there but that is a trade off we'd be prepared to manage in the wider
case

2.       A server-side flag that prevents a file from being opened at an
earlier revision - something like the check for the exclusive open flag.
This would actually solve it for both the P4Win client and the command
line but would seem to be a more significant change.

 

If there was a trigger on open-for-edit we might be able to work around
this ourselves but from the thread above, this appears to not be
available - is this correct?

 

The only option I can see atm is to force each client to refresh every
minute (when inactive) but this is still open to holes where the above
can still happen.

 

I'm keen to hear whether anyone else has come across this issue and
resolved it some other way?

 

Thanks,

Cj

 

_______________________________________________
perforce-user mailing list  -  perforce-user at perforce.com
http://maillist.perforce.com/mailman/listinfo/perforce-user




More information about the perforce-user mailing list