[PATCHv3 0/4] git-p4: fixing --changes-block-size handling

This series of patches teaches git-p4 to break up calls to the P4 server into smaller chunks, to avoid hitting the maxresults and maxscanrows server-side limits.

The previous iteration of this series didn't handle non-integer P4 revision ranges (e.g. //depot/...@2014/1/1,2015/1/1).

This version now breaks up the commit into blocks iff the revision range specified is an integer range: @all, M,N or N,#head. If the range is non-numeric then it falls back to relying on Perforce to parse the revisions. In this mode it is no longer possible to fetch changes in blocks (and requests to do so will be rejected).

Another alternative would be to turn the date (or whatever) revisions into numeric revision numbers, but there doesn't seem to be a simple way to do this. The best I can come up with is to get the changes "around" the date in question (perhaps binary-chopping from years down to seconds to find a range that works?) and then take the lowest revision supplied. But that's quite a bit more complex.

Luke Diamand (4):
  git-p4: additional testing of --changes-block-size
  git-p4: test with limited p4 server results
  git-p4: add tests for non-numeric revision range
  git-p4: fixing --changes-block-size handling

 git-p4.py               | 85 ++++++++++++++++++++++++++++++++++++-------------
 t/t9800-git-p4-basic.sh | 38 ++++++++++++++++++++++
 t/t9818-git-p4-block.sh | 73 ++++++++++++++++++++++++++++++++++++------
 3 files changed, 165 insertions(+), 31 deletions(-)