kernel/git - git - PowerEL Git System

Tree: d8245bb3fd

Author	SHA1	Message	Date
Sam Hocevar	1f90a64891	git-p4: reduce number of server queries for fetches When fetching changes from a depot using a full client spec, there is no need to perform as many queries as there are top-level paths in the client spec. Instead we query all changes in chronological order, also getting rid of the need to sort the results and remove duplicates. Signed-off-by: Sam Hocevar <sam@hocevar.net> Signed-off-by: Luke Diamand <luke@diamand.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>	9 years ago
Luke Diamand	785e70f467	git-p4: failing test case for skipping changes with multiple depots James Farwell reported that with multiple depots git-p4 would skip changes. http://article.gmane.org/gmane.comp.version-control.git/282297 Add a failing test case demonstrating the problem. Signed-off-by: Luke Diamand <luke@diamand.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>	9 years ago
Luke Diamand	1051ef0063	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>	10 years ago
Luke Diamand	6ba9e2c1ba	git-p4: test with limited p4 server results Change the --changes-block-size git-p4 test to use an account with limited "maxresults" and "maxscanrows" values. These conditions are applied in the server before the "-m maxchanges" parameter to "p4 changes" is applied, and so the strategy that git-p4 uses for limiting the number of changes does not work. As a result, the tests all fail. Note that "maxscanrows" is set quite high, as it appears to not only limit results from "p4 changes", but also limits results from "p4 print". Files that have more than "maxscanrows" changes seem (experimentally) to be impossible to print. There's no good way to work around this. Signed-off-by: Luke Diamand <luke@diamand.org> Acked-by: Lex Spoon <lex@lexspoon.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>	10 years ago
Luke Diamand	755113b903	git-p4: additional testing of --changes-block-size Add additional tests of some corner-cases of the --changes-block-size git-p4 parameter. Also reduce the number of p4 changes created during the tests, so that they complete faster. Signed-off-by: Luke Diamand <luke@diamand.org> Acked-by: Lex Spoon <lex@lexspoon.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>	10 years ago
Lex Spoon	96b2d54aee	git-p4: use -m when running p4 changes Simply running "p4 changes" on a large branch can result in a "too many rows scanned" error from the Perforce server. It is better to use a sequence of smaller calls to "p4 changes", using the "-m" option to limit the size of each call. Signed-off-by: Lex Spoon <lex@lexspoon.org> Acked-by: Luke Diamand <luke@diamand.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>	10 years ago