[p4] Weird trigger recursion behavior...
Chris Weiss
chris.weiss at gmail.com
Fri May 5 14:32:47 PDT 2006
The short description:
We've got a commit trigger that watches several files and if any one
is updated, fires up a Ruby script that copies the file contents over
the other files and submits them (actually, it does this for a matrix
of about 2000 files).
On our Windows test box, the trigger somehow seems to avoid recursion
problems. However, on our Linux test box, as soon as the trigger
notices one of the other files being checked in, it fires off again.
The Windows box is running Server version: P4D/NTX86/2005.1/89985 (2005/12/05)
The linux box is running Server version: P4D/LINUX26X86/2005.2/93627
(2006/02/14)
Is this something that's actually been "fixed" in the more recent
version of P4D?
Any suggestions on how to avoid the recursion problem? Our current
strategy is to update the Ruby script so that if it's called within a
second of the last execution, it just bails (there's only a few
engineers touching these files, so the odds of overlapping checkins
are minimal).
What posessed us to embrace such lunacy? Migrating from SourceGear
Vault to Perforce. SGV supports aliased files in it's database, P4 (as
near as we can tell) does not. Because the aliased files are
intermixed with non-aliased files and there's > 2000 of them,
branching or re-orging are more painful options than the script.
More information about the perforce-user
mailing list