git-p4: fixing --changes-block-size handling
authorLuke Diamand <luke@diamand.org>
Wed, 10 Jun 2015 07:30:59 +0000 (08:30 +0100)
committerJunio C Hamano <gitster@pobox.com>
Wed, 10 Jun 2015 15:29:17 +0000 (08:29 -0700)
commit1051ef00636357061d72bcf673da86054fb14a12
treeb22a0deb0f67a6249a57b4003b0e8e3287f8782b
parenteceafffbec97385eb65d7ba0c365ee028aaf1aad
git-p4: fixing --changes-block-size handling

The --changes-block-size handling was intended to help when
a user has a limited "maxscanrows" (see "p4 group"). It used
"p4 changes -m $maxchanges" to limit the number of results.

Unfortunately, it turns out that the "maxscanrows" and "maxresults"
limits are actually applied *before* the "-m maxchanges" parameter
is considered (experimentally).

Fix the block-size handling so that it gets blocks of changes
limited by revision number ($Start..$Start+$N, etc). This limits
the number of results early enough that both sets of tests pass.

Note that many other Perforce operations can fail for the same
reason (p4 print, p4 files, etc) and it's probably not possible
to workaround this. In the real world, this is probably not
usually a problem.

Signed-off-by: Luke Diamand <luke@diamand.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-p4.py
t/t9818-git-p4-block.sh