[p4] Submit triggers: how long is too long?

[Robert Cowham]

Don't forget that a commit trigger is fired after submit happens, and it
doesn't hold any locks. If it fails then an error message is still sent to
user for their submit (though of course submit has still happened so isn't
blocked on failure). It could also email people etc.

Can be combined with other suggestions...

> -----Original Message-----
> From: perforce-user-bounces at perforce.com 
> [mailto:perforce-user-bounces at perforce.com] On Behalf Of Greg 
> Whitfield
> Sent: 09 June 2006 09:25
> To: 'Stephen Vance'; 'Todd Short (tshort)'
> Cc: perforce-user at perforce.com
> Subject: Re: [p4] Submit triggers: how long is too long?
> 
> I would be tempted to use a separate branch and only allow 
> bugs to be submitted to this rather than your normal stable 
> line, and with no trigger to check whether a bug really 
> exists. You could then write a daemon a la P4Review that 
> processes recently submitted changelists and lets people know 
> if there was a lack of code review for a submission.
> 
> You can then schedule integrations from the bug fix line to 
> the stable line, but only for those changelists cleared by 
> the script. You could even get the script to generate the 
> commands to execute the per-changelist integrations, and 
> execute it at your leisure.
> 
> The separate script should have little or no performance 
> impact on Perforce irrespective of how many queries it makes 
> to the bug database. It should also be a bit more robust than 
> a trigger if, say, for some reason the bug database is 
> unavailable then your engineers are not blocked from submission.
> 
> Greg
> 
> 
> 
> 
> -----Original Message-----
> From: Stephen Vance [mailto:steve at vance.com]
> Sent: 09 June 2006 02:30
> To: Todd Short (tshort)
> Cc: perforce-user at perforce.com
> Subject: Re: [p4] Submit triggers: how long is too long?
> 
> Todd --
> 
> I believe databases and files are locked when the "submit" 
> trigger is invoked. That's definitely not a place to put undue delays.
> 
> If the databases are locked, others will be prevented from 
> submitting or doing just about anything else, for that 
> matter, since it affects have lists, revision records, 
> changelist records, etc.
> 
> I'd just make sure I had good baseline performance data 
> before I deployed this so I could characterize the impact.
> 
> Steve
> 
> Todd Short (tshort) wrote:
> > We are adding some additional process to our submission tasks. 
> > What we want to do is use a "submit" trigger to search a 
> database for 
> > the bug ID to see if a code review has taken place.
> >
> > At this point, I'm not sure how long this script will take, so my 
> > question is "How long is too long?"
> >
> > Does anyone know what kind of locking occurs when a submit 
> trigger is 
> > running? Are other people prevented from submitting? Or 
> just the files 
> > to be submitted? Syncing?
> >