[p4] Weird trigger recursion behavior...

[Weintraub, David]

A submit trigger that does submits. This of course, *SHOULD* call the
submit trigger again and again (and cause the recursion problem). And,
this *SHOULD* have been happening on both your Windows and Linux p4d
servers. The real question is why doesn't this happen on your Windows
server.

There are two reasons I can think of why this would happen:

1). In your Perforce triggers table, you can specify which files a
particular trigger is executed when a submit is done. It could be on
your Windows service, you've limited this submit trigger to a very
specific group of files. For example, you're watching for changes in
//depot/foo/bar.c and changes in this file will be copied to
//depot/bar/bar.c. In your Windows Perforce trigger table, you've
limited this submit trigger to only fire on //depot/foo/bar.c. When
//depot/bar/bar.c gets changed, the trigger isn't fired. You might want
to check your trigger tables in your Windows vs. Linux p4d servers to
see if this is the case.

2). The other reason could be in the Perforce submit trigger itself.
Whenever a submit is done, the submit trigger is executed, and if it
does a submit, you run the trigger again and again. In order to prevent
this, you normally have some sort of condition that exits the trigger
before it does another submit. It could be that your submit trigger is
making a certain assumption that is true on your Windows side, but not
on your Linux side.

For example, your Perforce p4d server on your Windows side is being run
with user ID 104643 while your Perforce server on your Linux side is
being run with user 1023. Somewhere in your trigger script, you say "if
the user who is executing this script is user #104643, then exit this
trigger script and don't do another submit". On Windows, this would
work, but not on Linux. Of course, there could be other conditions that
are met on Windows, but not on Linux that causes the Linux side to
recurse, but not the Windows side.

And, something else I've seen: You've accidentally put this condition in
your submit trigger. Through a side effect on your Windows side, this
condition is met, and you may not even be realizing it. Instead, you've
tested this trigger, it doesn't get recursive, and you're happy. Now,
you run this on your Linux side, that side effect doesn't exist, and
you're scratching your head why it's broken on Linux.

So, first check your Perforce trigger table and make sure they're set
the same. If they are, check your trigger script for the exit condition
that prevents recursion. If you can't find it, you'll have to debug this
trigger. Find a test file in your system, and create another submit
trigger that fires only on this one file. Copy the original submit
trigger to always fail (that is, the last line exits to a non-zero
value), and put in some debugging echo statements that print to STDOUT.
See if you can determine why trigger will work on Windows, but not on
Linux.

-----Original Message-----
From: perforce-user-bounces at perforce.com
[mailto:perforce-user-bounces at perforce.com] On Behalf Of Chris Weiss
Sent: Friday, May 05, 2006 5:33 PM
To: Perforce Users
Subject: [p4] Weird trigger recursion behavior...

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.

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