Re: [PATCH] perf: work around the tested repo having an index.lock

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Sun, Jun 4, 2017 at 9:37 AM, Christian Couder
<christian.couder@gmail.com> wrote:
> On Sun, Jun 4, 2017 at 2:00 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>>
>>>> My feeling exactly.  Diagnosing and failing upfront saying "well you
>>>> made a copy but it is not suitable for testing" sounds more sensible
>>>> at lesat to me.
>>>
>>> This change makes the repo suitable for testing when it wasn't before.
>>
>> Perhaps "not suitable" was a bit too vague.
>>
>> The copy you made is not in a consistent state that is good for
>> testing.  This change may declare that it is now in a consistent
>> state, but removal of a single *.lock file does not make it so.  We
>> do not know what other transient inconsistency the resulting copy
>> has; it is inherent to git-unaware copy---that is why we discouraged
>> and removed rsync transport after all.
>
> If we don't like git-unaware copies, maybe we should go back to the
> reasons why we are making one here.
> In 342e9ef2d9 (Introduce a performance testing framework, 2012-02-17),
> Thomas wrote:
>
>     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.
>
> Is a local clone really much slower these days? Wouldn't it is use
> hard links too?
> By the way the many properties that are preserved might not be worth
> preserving as they could make results depend a lot on the current
> state of the original repo.

AFAICT from some quick testing it'll hardlink the objects/ dir, so
e.g. you preserve the loose objects. Making the results depend on the
state of the original repo is a feature, but perhaps it should be opt
in. It's very useful to be able to take a repo that's accrued e.g. a
month's worth of refs & loose objects and test that v.s. a fresh
clone.

But there are other things that ever a hardlink local clone doesn't
preserve which might be worth preserving...