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