kernel/git - git - PowerEL Git System

42903 Commits

6 Branches

36 Tags

131 MiB

Tree: a1bc3dd464

Commit Graph

Author	SHA1	Message	Date
Thomas Rast	561ae06735	perf: export some important test-lib variables The only bug right now is that $GIT_TEST_CMP is needed for test_cmp to work. However, we also export the three most important paths for tests: TEST_DIRECTORY TRASH_DIRECTORY GIT_BUILD_DIR Since they are available within test_expect_success, a future test writer may expect them to also be defined in test_perf. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Thomas Rast	1cbc32403b	perf: load test-lib-functions from the correct directory Loading it in the subshells still referred to $TEST_DIRECTORY/.., which was only correct in preliminary versions of perf-lib.sh Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Thomas Rast	342e9ef2d9	Introduce a performance testing framework This introduces a performance testing framework under t/perf/. It tries to be as close to the test-lib.sh infrastructure as possible, and thus should be easy to get used to for git developers. The following points were considered for the implementation: 1. You usually want to compare arbitrary revisions/build trees against each other. They may not have the performance test under consideration, or even the perf-lib.sh infrastructure. To cope with this, the 'run' script lets you specify arbitrary build dirs and revisions. It even automatically builds the revisions if it doesn't have them at hand yet. 2. Usually you would not want to run all tests. It would take too long anyway. The 'run' script lets you specify which tests to run; or you can also do it manually. There is a Makefile for discoverability and 'make clean', but it is not meant for real-world use. 3. Creating test repos from scratch in every test is extremely time-consuming, and shipping or downloading such large/weird repos is out of the question. We leave this decision to the user. Two different sizes of test repos can be configured, and the scripts just copy one or more of those (using hardlinks for the object store). By default it tries to use the build tree's git.git repository. This is fairly fast and versatile. Using a copy instead of a clone preserves many properties that the user may want to test for, such as lots of loose objects, unpacked refs, etc. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago

Author

SHA1

Message

Date

Thomas Rast

561ae06735

perf: export some important test-lib variables

The only bug right now is that $GIT_TEST_CMP is needed for test_cmp to
work.

However, we also export the three most important paths for tests:

  TEST_DIRECTORY
  TRASH_DIRECTORY
  GIT_BUILD_DIR

Since they are available within test_expect_success, a future test
writer may expect them to also be defined in test_perf.

Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

13 years ago

Thomas Rast

1cbc32403b

perf: load test-lib-functions from the correct directory

Loading it in the subshells still referred to $TEST_DIRECTORY/..,
which was only correct in preliminary versions of perf-lib.sh

Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

13 years ago

Thomas Rast

342e9ef2d9

Introduce a performance testing framework

This introduces a performance testing framework under t/perf/.  It
tries to be as close to the test-lib.sh infrastructure as possible,
and thus should be easy to get used to for git developers.

The following points were considered for the implementation:

1. You usually want to compare arbitrary revisions/build trees against
   each other.  They may not have the performance test under
   consideration, or even the perf-lib.sh infrastructure.

   To cope with this, the 'run' script lets you specify arbitrary
   build dirs and revisions.  It even automatically builds the revisions
   if it doesn't have them at hand yet.

2. Usually you would not want to run all tests.  It would take too
   long anyway.  The 'run' script lets you specify which tests to run;
   or you can also do it manually.  There is a Makefile for
   discoverability and 'make clean', but it is not meant for
   real-world use.

3. Creating test repos from scratch in every test is extremely
   time-consuming, and shipping or downloading such large/weird repos
   is out of the question.

   We leave this decision to the user.  Two different sizes of test
   repos can be configured, and the scripts just copy one or more of
   those (using hardlinks for the object store).  By default it tries
   to use the build tree's git.git repository.

   This is fairly fast and versatile.  Using a copy instead of a clone
   preserves many properties that the user may want to test for, such
   as lots of loose objects, unpacked refs, etc.

Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

13 years ago

3 Commits (a1bc3dd46433c6e7e6f1ca5f3bd5429858a60078)