[PATCH 3 of 9 stable] tests: don't rely on broken behaviour in test-largefiles-cache.t

Mads Kiilerich mads at kiilerich.com
Tue Feb 26 12:11:36 CST 2013


On 02/26/2013 06:16 AM, Kevin Bullock wrote:
> On 25 Feb 2013, at 8:41 PM, Mads Kiilerich wrote:
>
>> # HG changeset patch
>> # User Mads Kiilerich <madski at unity3d.com>
>> # Date 1361846443 -3600
>> # Branch stable
>> # Node ID c92e62e6b93838c00c749e85e4eab243e155dd58
>> # Parent  27f081501f9e04320ac94654c61e766764ee159e
>> tests: don't rely on broken behaviour in test-largefiles-cache.t
>>
>> The test relied on the bug that 'pull largefiles from branchheads' didn't pull
>> any largefiles from tip revision when it seemed like no largefiles had been
>> checked out before.
>>
>> diff --git a/tests/test-largefiles-cache.t b/tests/test-largefiles-cache.t
>> --- a/tests/test-largefiles-cache.t
>> +++ b/tests/test-largefiles-cache.t
>> @@ -16,6 +16,9 @@
>>    $ echo large > large
>>    $ hg add --large large
>>    $ hg commit -m 'add largefile'
>> +  $ hg rm large
>> +  $ hg commit -m 'branchhead without largefile'
>> +  $ hg up -qr 0
>>    $ cd ..
>>
>> Discard all cached largefiles in USERCACHE
>> @@ -24,7 +27,7 @@
>>
>> Create mirror repo, and pull from source without largefile:
>> "pull" is used instead of "clone" for suppression of (1) updating to
>> -tip (= cahcing largefile from source repo), and (2) recording source
>> +tip (= caching largefile from source repo), and (2) recording source
> Looks like an unrelated spelling fix?

Absolutely correct. In the descriptive part of a test.

The guidelines requiring no unrelated changes are good and do serve a 
purpose. But sometimes it serve no purpose to follow them literally. 
They are an attempt of formalizing and generalizing the intention.

In this case I was doing trivial cleanup of the test file anyway. There 
is no way this could make a review harder or hide bugs or that anybody 
would care to apply or bisect one without the other. Fixing a typo in 
the passing in such a patch adds less overhead to the whole process than 
doing it in a separate patch. All time spent handling and discussing 
such a minor nice-to-have is a waste of time.

Please, let's get the proportions right and focus on stuff that matters.

/Mads



More information about the Mercurial-devel mailing list