[PATCHv1 0/3] git-p4: improvements to p4 "blocking"

This patchset improves the way that git-p4 sends requests in "blocks".

The problem comes about because the Perforce server limits the maximum number of results it will send back (there are actually two different limits).

This causes git-p4 failures if you ask for too much data.

In commit 96b2d54aee ("git-p4: use -m when running p4 changes", 2015-04-20), git-p4 learned to make requests in blocks, by default 512 in size.

The problem with this, however, is that it can be very slow on large repositories - you might have millions of commits, although only a handful actually relate to the code you are trying to clone. Each 512 block request takes a sizeable fraction of a second to complete.

There's a command-line option to increase the block size, but unless you know about it, it won't be at all obvious that you could use this to speed things up.

This change ~~~~~~~~~~~

The function p4CmdList() has been taught to raise an exception when it gets an error, and in particular, to notice and report the two "too many results" errors.

The code that does the blocking can now start out with a nice large block size, and then reduce it if it sees an error.

Luke Diamand (3):
  git-p4: raise exceptions from p4CmdList based on error from p4 server
  git-p4: narrow the scope of exceptions caught when parsing an int
  git-p4: auto-size the block

 git-p4.py               | 72 +++++++++++++++++++++++++++++++++++------
 t/t9818-git-p4-block.sh | 11 +++++++
 2 files changed, 73 insertions(+), 10 deletions(-)