At 02:02 PM 12/24/2002 -0500, Stephen Vance wrote:
More daunting are the performance questions. What is the status of the database
locks during this operation?
This is the big issue. In order to commit each change as an atomic
transaction, Perforce locks the files in the change until all the modifications
are entered into the depot. This blocks other actions that overlap in scope
with the submit. To do otherwise would be to serve corrupt data.
Submit-time triggers would cause immediately-noticeable performance
issues for all clients unless the semantics of 'p4 submit' were altered to
allow triggers to run before the locks were set. This would worsen the
race condition for the submitter by lengthening the window during which
someone else's submit could cause rejection of the submit pending a
merge.
This works under CVS because CVS makes no guarantees about data
coherence, and so does not need as thorough a locking scheme as
Perforce has.
8 messages in com.perforce.perforce-user[p4] Post pre-submit triggers...
