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

[Luke Diamand <luke@diamand.org>]

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

-- 
2.4.1.502.gb11c5ab