We have a situation where we have a lot of different types of projects in a source tree. Some of them I would call 'support' or 'common' projects that a lot of the other sub-projects use. We want all of these support projects to be up to date when a build of a real project gets triggered. As we have dozens of these projects, and they are added and taken away constantly, it's impractical to have a P4 sync command that covers all these things and keeps the support projects up to date, while at the same time ignoring all the other 'real' projects we would want to trigger a build. Right now I have a 'p4 sync' command running every five minutes from the top level, but what this means is that I lose the ability to monitor projects under the same tree.

What I would like to do is run a global p4 sync update in, say, //DotNet/main/Source/..., but retain the ability to trigger a build within that tree, say at //DotNet/main/Source/CoolProject/...

As it stands, if the first sync 'build' happens before the trigger for the 'Cool Project' build, the command 'p4 sync //DotNet/main/Source/CoolProject/...' will return 'all files up to date' and no build will happen.

It might be a better, more accurate scheme to use 'p4 changes' instead of 'p4 sync' when triggering builds for Perforce repositories. It's not entirely simple, as each build plan would have to track some kind of counter which would save the results from the previous 'p4 changes' command, but the build triggers would be more explicit and would not rely on a 'p4 sync' command that could conceivably be run by anyone at any time, thus voiding many possible build triggers.

It hasn't come up with us, but I could also see a time when one would want a certain checkin of a common library to trigger multiple builds. We can't do this now because 1) We can't monitor multiple repository paths (different issue) and 2) even if we could do #1 the first plan to sync this particular path would 'win' and no other plans below that would trigger a build.