Re: [PATCHv1 0/3] git-p4: fixing --changes-block-size support
- From
Luke Diamand <luke@diamand.org>
- Date
- Jun 7, 2015, 16:58 UTC
- Message-ID
- <55747846.3060305@diamand.org>
- In-Reply-To
- <CALM2Sna_sdD_95MO3EbF0+QSpB9W1K8Rv3-TNOmnovWG57gh7g@mail.gmail.com>
On 07/06/15 17:01, Lex Spoon wrote:
> Great work.
Thanks! I actually found the problem in my day job, so it was very handy having all the infrastructure already in place!
> > For curiosity's sake, the -m solution has been observed to work on at > least one Perforce installation. However clearly it doesn't work on > others, so the batch ranges approach looks like it will be better.
Yes, I can easily imagine that it's changed from one version to the next. I tried going back to a 2014.2 server which still had the same problem (with maxresults), but my investigations were not very exhaustive!
Show 6 quoted lines
> > Based on what has been seen so far, the Perforce maxscanrows setting > must be applying the low-level database queries that Perforce uses > internally in its implementation. That makes the precise effect on > external queries rather hard to predict. It likely also depends on the > version of Perforce.
Indeed. All sorts of things can cause it to fail; I've seen it reject "p4 files" and "p4 print", albeit with artificially low maxscanrows and maxresults values. I think this means there's no way to ever make it reliably work for all possible sizes of depot and values of maxscanrows/maxresults.
Luke