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

Matt Mackall mpm at selenic.com
Tue Feb 26 13:30:04 CST 2013


On Tue, 2013-02-26 at 19:11 +0100, Mads Kiilerich wrote:
> 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. 

Breaking the rules is a false efficiency as the probability of
triggering an expensive rules discussion and/or resend is high. 
Further, the probability of triggering the expense does not drop in
proportion to the value of the unrelated change, so the expected
cost/benefit ratio goes to infinity as the value of the unrelated change
goes to zero.

So please do not break the rules, especially for nearly-zero-value
changes like typos in test descriptions. Better to not make such changes
at all than to spend an hour discussing them.

-- 
Mathematics is the supreme nostalgia of our time.




More information about the Mercurial-devel mailing list