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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]