Skip to content
Snippets Groups Projects
  • Augie Fackler's avatar
    2d6b86cadc10
    tests: correct (I think) command in test-largefiles-update · 2d6b86cadc10
    Augie Fackler authored
    When this test was introduced, it used the short-form of all the flags
    on this update invocation. I suspect, based on the "start with clean
    dirstates" comment and the fact that the no-exec branch of the #if
    guard leaves dirstate clean, that this should have been 'update -qCr'
    instead of 'update -qcr', but that a bug in largefiles --check
    handling left this problem unnoticed.
    
    I'll leave a breadcrumb further up about the current failure mode in
    the hopes that we can fix this some day.
    
    This was previously discussed in [0] but the trail in that thread goes
    cold after a few replies. Given that this is still a flaky test, that
    appears to only be passing by bad fortune, I think it's worth
    correcting the code of the test to make a correct assertion, and to
    keep track of the suspected bug with some other mechanism than an
    invalid test (if we had support for "expected failure" blocks this
    might be a worthwhile use of them?).
    
    0: https://www.mercurial-scm.org/pipermail/mercurial-devel/2016-October/089501.html
    2d6b86cadc10
    History
    tests: correct (I think) command in test-largefiles-update
    Augie Fackler authored
    When this test was introduced, it used the short-form of all the flags
    on this update invocation. I suspect, based on the "start with clean
    dirstates" comment and the fact that the no-exec branch of the #if
    guard leaves dirstate clean, that this should have been 'update -qCr'
    instead of 'update -qcr', but that a bug in largefiles --check
    handling left this problem unnoticed.
    
    I'll leave a breadcrumb further up about the current failure mode in
    the hopes that we can fix this some day.
    
    This was previously discussed in [0] but the trail in that thread goes
    cold after a few replies. Given that this is still a flaky test, that
    appears to only be passing by bad fortune, I think it's worth
    correcting the code of the test to make a correct assertion, and to
    keep track of the suspected bug with some other mechanism than an
    invalid test (if we had support for "expected failure" blocks this
    might be a worthwhile use of them?).
    
    0: https://www.mercurial-scm.org/pipermail/mercurial-devel/2016-October/089501.html