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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
