Skip to content
Snippets Groups Projects
  1. Sep 06, 2019
  2. Sep 03, 2019
  3. Sep 25, 2019
  4. Sep 23, 2019
  5. Sep 25, 2019
  6. Sep 21, 2019
  7. Sep 25, 2019
  8. May 20, 2019
  9. Sep 18, 2019
  10. Sep 17, 2019
    • Kyle Lippincott's avatar
      transaction: detect an attempt to truncate-to-extend on playback, raise error · 8502f76dbfd7
      Kyle Lippincott authored
      On some networked filesystems, writes can have delayed finalization/confirmation
      and write races can occur such that a remote modification will "win" and
      modifications will be lost. There is no functionality for providing this
      feedback to userspace programs (in fact, there's not even functionality for
      providing this information to the Linux kernel...), so these programs may see
      the files suddenly change.
      
      We've noticed that there have been cases where Mercurial has detected something
      has gone wrong and attempts to abort (rolling back the transaction), which is
      good. However, when rolling back the transaction, for the append-only files,
      we attempt to "truncate" the file back to the size it was in before the hg
      transaction started, but end up *extending* it. This may be harmless, but if
      this happens to the 00changelog.i file, we get a bunch of nulls on the end of
      the file and this causes hg to become *really* confused. :)
      
      If we detect that some modification of the file outside of this Mercurial
      process has caused the file to be smaller than the size we are attempting to
      truncate to, let's just exit and stop trying to clean up the repository -
      continuing will likely just cause more damage.
      
      Differential Revision: https://phab.mercurial-scm.org/D6867
      8502f76dbfd7
    • Kyle Lippincott's avatar
      d6227c6c0814
    • Kyle Lippincott's avatar
      osutil: allow disabling setprocname via a define passed to the compiler · 460f8bf58020
      Kyle Lippincott authored
      In some situations, we run a custom python launcher that appears to not set up
      Py_GetArgcArgv correctly. We then proceed to promptly crash when we attempt to
      dereference NULL. Being able to completely disable setprocname is beneficial in
      these situations, since we won't even attempt to use it, even if the case that
      causes the crash is fixed.
      
      Right now, if I compile osutil.so with -DSETPROCNAME_USE_NONE, the compilation
      fails on python3 due to SETPROCNAME_USE_NONE redefinition. I could possibly
      work around that, but it's likely helpful to have a way of disabling this
      completely without it being brittle (i.e. if python3 ever gains the ability to
      perform this operation).
      
      Differential Revision: https://phab.mercurial-scm.org/D6865
      460f8bf58020
  11. Sep 22, 2019
    • Anton Shestakov's avatar
      stack: use repo.revs() instead of revsetlang.formatspec() + scmutil.revrange() · 763028fc6a69
      Anton Shestakov authored
      Using scmutil.revrange() it's possible to use multiple revsets at the same
      time, but we're not using that functionality in stack.
      
      I thought maybe that function could be used to make stack definition
      customizable (by combining various parts into one set), but scmutil.revrange()
      gives the union of all provided revsets, which is not very useful in stack's
      case (we want "and" between parts, not "or").
      763028fc6a69
  12. Sep 23, 2019
  13. Sep 20, 2019
  14. Sep 01, 2019
  15. Sep 18, 2019
Loading