[p4] Weird trigger recursion behavior...

[Jamison, Shawn]

Yes.  Extract as many of the 2000 files out to a "common" area and so you only have to update one file in one place.  You will also have to modify your build process as well but from your description it would be worth it.

-Shawn Jamison>


-----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