[p4] Weird trigger recursion behavior...

[Chris Weiss]

So each developer would have to manage a several thousand line
workspace spec? Some unknowns there are how large a workspace spec can
P4 process and what kind of performance hit the server takes
processing it.

On 5/7/06, Jamison, Shawn <sjamison at ciena.com> wrote:
> 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
>