From: Matheus Tavares Bernardino <matheus.bernardino@usp.br>
To: Derrick Stolee <stolee@gmail.com>
Cc: git <git@vger.kernel.org>,
Christian Couder <christian.couder@gmail.com>,
Jeff Hostetler <git@jeffhostetler.com>,
Jonathan Nieder <jrnieder@gmail.com>
Subject: Re: [PATCH 4/7] parallel-checkout: add tests for basic operations
Date: Mon, 26 Apr 2021 23:30:08 -0300 [thread overview]
Message-ID: <CAHd-oW7-Lv9hZZGDjVHjvDKvYpJ0wektVVPNrazZ441K25SczQ@mail.gmail.com> (raw)
In-Reply-To: <1b1cdef5-7d90-c6f3-ea8d-e1c9d472ffff@gmail.com>
On Fri, Apr 23, 2021 at 4:18 PM Derrick Stolee <stolee@gmail.com> wrote:
>
> On 4/22/2021 11:17 AM, Matheus Tavares wrote:
> > Add tests to populate the working tree during clone and checkout using
> > sequential and parallel mode, to confirm that they produce identical
> > results. Also test basic checkout mechanics, such as checking for
> > symlinks in the leading directories and the abidance to --force.
> >
> > Note: some helper functions are added to a common lib file which is only
> > included by t2080 for now. But they will also be used by other
> > parallel-checkout tests in the following patches.
> >
> > Original-patch-by: Jeff Hostetler <jeffhost@microsoft.com>
>
> Is this a standard thing? Or, did you change the patch significantly
> enough that "Co-authored-by:" is no longer appropriate?
No, I think "Co-authored-by" is appropriate, let's change this trailer :)
> > +++ b/t/lib-parallel-checkout.sh
> > @@ -0,0 +1,37 @@
> > +# Helpers for t208* tests
>
> I could see tests outside of the t208* range possibly having
> value in interacting with parallel checkout in the future.
>
> Perhaps:
>
> # Helpers for tests invoking parallel-checkout
Will do!
> > +
> > +set_checkout_config () {
> > + if test $# -ne 2
> > + then
> > + BUG "set_checkout_config() requires two arguments"
> > + fi &&
>
> A usage comment is typically helpful for these helpers:
>
> # set_checkout_config <workers> <threshold>
> # sets global config values to use the given number of
> # workers when the given threshold is met.
OK, I'll change that.
> > +
> > + test_config_global checkout.workers $1 &&
> > + test_config_global checkout.thresholdForParallelism $2
> > +}
> > +
> > +# Run "${@:2}" and check that $1 checkout workers were used
> > +test_checkout_workers () {
>
> This simpler doc style works, too.
>
> > + if test $# -lt 2
> > + then
> > + BUG "too few arguments to test_checkout_workers()"
> > + fi &&
> > +
> > + expected_workers=$1 &&
> > + shift &&
> > +
> > + rm -f trace &&
> > + GIT_TRACE2="$(pwd)/trace" "$@" &&
> > +
> > + workers=$(grep "child_start\[..*\] git checkout--worker" trace | wc -l) &&
> > + test $workers -eq $expected_workers &&
> > + rm -f trace
>
> I wonder if this should be a "test_when_finished rm -f trace" being
> recorded earlier in the step.It would also benefit from using a more
> specific name than "trace". Something like "trace-test-checkout-workers"
> would be unlikely to collide with someone else's trace.
Good idea, I'll change the trace file name.
Unfortunately, I think we won't be able to use `test_when_finished`
here as this function is sometimes called inside subshells, and
`test_when_finished` doesn't work in this situation :(
> > +# Verify that both the working tree and the index were created correctly
> > +verify_checkout () {
>
> Add usage of a repo in $1?
Sure!
> > + git -C "$1" diff-index --quiet HEAD -- &&
> > + git -C "$1" diff-index --quiet --cached HEAD -- &&
> > + git -C "$1" status --porcelain >"$1".status &&
> > + test_must_be_empty "$1".status
> > +}
>
>
> > +TEST_NO_CREATE_REPO=1
> > +. ./test-lib.sh
> > +. "$TEST_DIRECTORY/lib-parallel-checkout.sh"
> > +
> > +# Test parallel-checkout with a branch switch containing file creations,
> > +# deletions, and modification; with different entry types. Switching from B1 to
> > +# B2 will have the following changes:
> > +#
> > +# - a (file): modified
> > +# - e/x (file): deleted
> > +# - b (symlink): deleted
> > +# - b/f (file): created
> > +# - e (symlink): created
> > +# - d (submodule): created
> > +#
>
> An interesting set of changes. What about a directory/file conflict?
>
> Something like this might be useful:
>
> # - f/t (file): deleted
> # - f (file): created
>
> in fact, it could be interesting to have a file conflict with each
> of these types, such as the symlink 'e' and the submodule 'd'.
Sure, I'll add those. (But we already have the symlink case with 'e/x'
(file) and 'e' (symlink), no?)
> While we are at it, what about a symlink/submodule conflict? I know
> it makes the test bigger, but doing everything simultaneously through
> a carefully designed repository helps prevent test case bloat.
>
> > +test_expect_success SYMLINKS 'setup repo for checkout with various types of changes' '
>
> Could we split this setup step into two parts? Once could
> set up everything except the symlinks and would not require
> the SYMLINKS prereq. We could then have another test with
> the SYMLINKS prereq that extends B1 and B2 to have symlinks
> and their conflicts. The remaining tests would work on any
> platform without needing the SYMLINKS prereq.
Good point. I think we might be able to create the symlinks with
`test_ln_s_add` and completely get rid of the SYMLINKS prereq :)
> > +test_expect_success SYMLINKS 'sequential checkout' '
> > + cp -R various various_sequential &&
> > + set_checkout_config 1 0 &&
> > + test_checkout_workers 0 \
> > + git -C various_sequential checkout --recurse-submodules B2 &&
> > + verify_checkout various_sequential
> > +'
>
> I see all these tests are very similar. Perhaps group
> them to demonstrate their differences?
Makes sense, I'll do that.
> parallel_test_case () {
> test_expect_success "$1" "
> cp -R various $2 &&
> set_checkout_config $3 $4 &&
> test_checkout_workers $5 \
> git -C $2 checkout --recurse-submodules B2 &&
> verify_checkout $2
> "
> }
>
> parallel_test_case 'sequential checkout' \
> various_sequential 1 0 0
> parallel_test_case 'parallel checkout' \
> various_parallel 2 0 2
> parallel_test_case 'fallback to sequential checkout (threshold)' \
> various_sequential_fallback 2 100 0
>
> > +test_expect_success SYMLINKS 'parallel checkout on clone' '
> > + git -C various checkout --recurse-submodules B2 &&
> > + set_checkout_config 2 0 &&
> > + test_checkout_workers 2 \
> > + git clone --recurse-submodules various various_parallel_clone &&
> > + verify_checkout various_parallel_clone
> > +'
next prev parent reply other threads:[~2021-04-27 2:30 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-22 15:17 [PATCH 0/7] Parallel Checkout (part 3) Matheus Tavares
2021-04-22 15:17 ` [PATCH 1/7] make_transient_cache_entry(): optionally alloc from mem_pool Matheus Tavares
2021-04-22 15:17 ` [PATCH 2/7] builtin/checkout.c: complete parallel checkout support Matheus Tavares
2021-04-23 16:19 ` Derrick Stolee
2021-04-26 21:54 ` Matheus Tavares Bernardino
2021-04-22 15:17 ` [PATCH 3/7] checkout-index: add " Matheus Tavares
2021-04-23 18:32 ` Derrick Stolee
2021-04-26 22:30 ` Matheus Tavares Bernardino
2021-04-22 15:17 ` [PATCH 4/7] parallel-checkout: add tests for basic operations Matheus Tavares
2021-04-23 19:18 ` Derrick Stolee
2021-04-27 2:30 ` Matheus Tavares Bernardino [this message]
2021-04-22 15:17 ` [PATCH 5/7] parallel-checkout: add tests related to path collisions Matheus Tavares
2021-04-22 15:17 ` [PATCH 6/7] parallel-checkout: add tests related to .gitattributes Matheus Tavares
2021-04-23 19:48 ` Derrick Stolee
2021-04-22 15:17 ` [PATCH 7/7] ci: run test round with parallel-checkout enabled Matheus Tavares
2021-04-23 19:56 ` Derrick Stolee
2021-04-30 21:40 ` [PATCH v2 0/8] Parallel Checkout (part 3) Matheus Tavares
2021-04-30 21:40 ` [PATCH v2 1/8] make_transient_cache_entry(): optionally alloc from mem_pool Matheus Tavares
2021-05-01 17:06 ` Christian Couder
2021-05-03 14:11 ` Matheus Tavares Bernardino
2021-04-30 21:40 ` [PATCH v2 2/8] builtin/checkout.c: complete parallel checkout support Matheus Tavares
2021-05-01 17:08 ` Christian Couder
2021-05-03 14:21 ` Matheus Tavares Bernardino
2021-04-30 21:40 ` [PATCH v2 3/8] checkout-index: add " Matheus Tavares
2021-05-01 17:08 ` Christian Couder
2021-05-03 14:22 ` Matheus Tavares Bernardino
2021-04-30 21:40 ` [PATCH v2 4/8] parallel-checkout: add tests for basic operations Matheus Tavares
2021-04-30 21:40 ` [PATCH v2 5/8] parallel-checkout: add tests related to path collisions Matheus Tavares
2021-05-02 7:59 ` Torsten Bögershausen
2021-05-03 14:58 ` Matheus Tavares Bernardino
2021-04-30 21:40 ` [PATCH v2 6/8] t0028: extract encoding helpers to lib-encoding.sh Matheus Tavares
2021-04-30 21:40 ` [PATCH v2 7/8] parallel-checkout: add tests related to .gitattributes Matheus Tavares
2021-04-30 21:40 ` [PATCH v2 8/8] ci: run test round with parallel-checkout enabled Matheus Tavares
2021-05-02 10:12 ` [PATCH v2 0/8] Parallel Checkout (part 3) Torsten Bögershausen
2021-05-03 15:01 ` Matheus Tavares Bernardino
2021-05-04 16:27 ` [PATCH v3 " Matheus Tavares
2021-05-04 16:27 ` [PATCH v3 1/8] make_transient_cache_entry(): optionally alloc from mem_pool Matheus Tavares
2021-05-04 16:27 ` [PATCH v3 2/8] builtin/checkout.c: complete parallel checkout support Matheus Tavares
2021-05-05 13:55 ` Derrick Stolee
2021-05-04 16:27 ` [PATCH v3 3/8] checkout-index: add " Matheus Tavares
2021-05-04 16:27 ` [PATCH v3 4/8] parallel-checkout: add tests for basic operations Matheus Tavares
2021-05-26 18:36 ` AIX failures on parallel checkout (new in v2.32.0-rc*) Ævar Arnfjörð Bjarmason
2021-05-26 22:01 ` Matheus Tavares Bernardino
2021-05-26 23:00 ` Junio C Hamano
2021-05-04 16:27 ` [PATCH v3 5/8] parallel-checkout: add tests related to path collisions Matheus Tavares
2021-05-04 16:27 ` [PATCH v3 6/8] t0028: extract encoding helpers to lib-encoding.sh Matheus Tavares
2021-05-04 16:27 ` [PATCH v3 7/8] parallel-checkout: add tests related to .gitattributes Matheus Tavares
2021-05-04 16:27 ` [PATCH v3 8/8] ci: run test round with parallel-checkout enabled Matheus Tavares
2021-05-05 13:57 ` [PATCH v3 0/8] Parallel Checkout (part 3) Derrick Stolee
2021-05-06 0:40 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAHd-oW7-Lv9hZZGDjVHjvDKvYpJ0wektVVPNrazZ441K25SczQ@mail.gmail.com \
--to=matheus.bernardino@usp.br \
--cc=christian.couder@gmail.com \
--cc=git@jeffhostetler.com \
--cc=git@vger.kernel.org \
--cc=jrnieder@gmail.com \
--cc=stolee@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).