[JIRA] (JENKINS-15653) Filter changes by viewspec

[bgold...@synopsys.com (JIRA)]

Ben Golding commented on JENKINS-15653 Filter changes by viewspec I don't see a big time difference between fstat/describe. Each takes around 0.1 second in my tests: bash-2.05b$ time p4 -c VPOM6430_bgolding-e4310 describe -s 2448248 | wc 1809 5408 225392 real 0m0.085s user 0m0.010s sys 0m0.020s $ time p4 -c VPOM6430_bgolding-e4310 fstat -Rc -e 2448248 //... | wc 1352 3557 46302 real 0m0.060s user 0m0.000s sys 0m0.010s Anyhow I'm not really sure whether time to complete is an important metric. The fstat commands could be run in a background thread, in parallel with the actual build. Multiple commands can also be batched up with p4 -x <file>. [Of course, either describe or fstat could benefit from such improvements] Regarding network traffic / filtering efficiency: it depends what % of the files in each changelist are mapped to the client. In the worst case, fstat has almost 300% overhead vs. describe, but with -T only ~ 2%. Regarding -s and -T switches: I assumed your plugin already queries the server version, and adjusts p4 commands appropriately. Anyhow we should not complain about inefficiency while also taking a 'lowest common denominator' approach. Bottom line: Which is faster/better comes down to many variables: p4d version; bandwidth; latency; server load/performance; size of server depot; # files in typical changelist; # files in typical client; etc. So I suggest to let the user decide whether to enable filtering or not, perhaps even in a per-client advanced setting. For me, this is a very important missing feature when doing triage of broken builds, and saves much more (human) time than a few seconds (machine time) overhead of fstat commands.

This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira