Skip to content
Snippets Groups Projects
  1. Feb 22, 2025
  2. May 02, 2022
  3. Jan 10, 2022
  4. Dec 08, 2021
  5. Nov 10, 2021
  6. Oct 19, 2021
    • Pierre-Yves David's avatar
      dirstate-v2: freeze the on-disk format · bf11ff22a9af
      Pierre-Yves David authored
      It seems the format as reached a good balance. With a core of new capabilities
      that motivated it initially and enough new feature and room for future
      improvement to be a clear progress we can set a milestone for.
      
      Having the format frozen will help the feature to get real life testing, outside
      of the test suite.
      
      The feature itself stay experimental but the config gains a new name to avoid
      people enable non-frozen version by default.
      
      If too many bugs are reported during the RC we might move the format back to
      experimental and drop its support in future version (in favor of a new one)
      
      Differential Revision: https://phab.mercurial-scm.org/D11709
      bf11ff22a9af
  7. Jun 09, 2021
  8. Jun 08, 2021
  9. May 28, 2021
  10. May 30, 2021
  11. May 19, 2021
  12. May 18, 2021
  13. May 19, 2021
  14. May 04, 2021
  15. May 03, 2021
  16. Jan 14, 2021
  17. Apr 06, 2021
  18. Jan 28, 2021
  19. Dec 10, 2020
  20. Nov 23, 2020
  21. Jul 21, 2020
  22. Jan 10, 2019
    • Gregory Szorc's avatar
      revlog: always enable generaldelta on version 2 revlogs · e7a2cc84dbc0
      Gregory Szorc authored
      This commit starts the process of diverging version 2 revlogs
      from version 1 revlogs.
      
      generaldelta is a useful feature and has been enabled by
      default for ages. I can't think of a good reason why the
      feature should be disabled. Yes, it is true changelogs
      today don't have generaldelta enabled. But that's because
      they don't have delta chains enabled, so generaldelta makes
      no sense there.
      
      This commit makes generaldelta always enabled on version 2
      revlogs.
      
      As part of this, one-off code in changelog.py mucking with
      revlog.version had to be made conditional on the revlog
      version, as we don't want to change revlog feature
      flags on version 2 revlogs. The fact this code exists
      is horrible and stems from revlog options being shared by
      the opener. We probably want a better API here. But that can
      wait for another patch.
      
      Differential Revision: https://phab.mercurial-scm.org/D5561
      e7a2cc84dbc0
  23. Nov 12, 2018
  24. Jun 18, 2018
  25. Apr 04, 2018
  26. Feb 28, 2018
  27. May 20, 2017
    • Gregory Szorc's avatar
      revlog: skeleton support for version 2 revlogs · 19b9fc40cc51
      Gregory Szorc authored
      There are a number of improvements we want to make to revlogs
      that will require a new version - version 2. It is unclear what the
      full set of improvements will be or when we'll be done with them.
      What I do know is that the process will likely take longer than a
      single release, will require input from various stakeholders to
      evaluate changes, and will have many contentious debates and
      bikeshedding.
      
      It is unrealistic to develop revlog version 2 up front: there
      are just too many uncertainties that we won't know until things
      are implemented and experiments are run. Some changes will also
      be invasive and prone to bit rot, so sitting on dozens of patches
      is not practical.
      
      This commit introduces skeleton support for version 2 revlogs in
      a way that is flexible and not bound by backwards compatibility
      concerns.
      
      An experimental repo requirement for denoting revlog v2 has been
      added. The requirement string has a sub-version component to it.
      This will allow us to declare multiple requirements in the course
      of developing revlog v2. Whenever we change the in-development
      revlog v2 format, we can tweak the string, creating a new
      requirement and locking out old clients. This will allow us to
      make as many backwards incompatible changes and experiments to
      revlog v2 as we want. In other words, we can land code and make
      meaningful progress towards revlog v2 while still maintaining
      extreme format flexibility up until the point we freeze the
      format and remove the experimental labels.
      
      To enable the new repo requirement, you must supply an experimental
      and undocumented config option. But not just any boolean flag
      will do: you need to explicitly use a value that no sane person
      should ever type. This is an additional guard against enabling
      revlog v2 on an installation it shouldn't be enabled on. The
      specific scenario I'm trying to prevent is say a user with a
      4.4 client with a frozen format enabling the option but then
      downgrading to 4.3 and accidentally creating repos with an
      outdated and unsupported repo format. Requiring a "challenge"
      string should prevent this.
      
      Because the format is not yet finalized and I don't want to take
      any chances, revlog v2's version is currently 0xDEAD. I figure
      squatting on a value we're likely never to use as an actual revlog
      version to mean "internal testing only" is acceptable. And
      "dead" is easily recognized as something meaningful.
      
      There is a bunch of cleanup that is needed before work on revlog
      v2 begins in earnest. I plan on doing that work once this patch
      is accepted and we're comfortable with the idea of starting down
      this path.
      19b9fc40cc51
Loading