Skip to content
Snippets Groups Projects
  1. Jul 05, 2017
  2. Jul 01, 2017
  3. Jun 28, 2017
    • Pierre-Yves David's avatar
      obsolete: reports the number of local changeset obsoleted when unbundling · 53b3a196
      Pierre-Yves David authored
      This is a first basic visible usage of the changes tracking in the transaction.
      We adds a new function computing the pre-existing changesets obsoleted by a
      transaction and a transaction call back displaying this information.
      
      Example output:
      
        added 1 changesets with 1 changes to 1 files (+1 heads)
        3 new obsolescence markers
        obsoleted 1 changesets
      
      The goal is to evolve the transaction summary into something bigger, gathering
      existing output there and adding new useful one. This patch is a good first step
      on this road. The new output is basic but give a user to the content of
      tr.changes['obsmarkers'] and give an idea of the new options we haves. I expect
      to revisit the message soon.
      
      The caller recording the transaction summary should also be moved into a more
      generic location but further refactoring is needed before it can happen.
      53b3a196
  4. Jul 02, 2017
    • Katsunori FUJIWARA's avatar
    • Katsunori FUJIWARA's avatar
      tests: make output lines conditional for testing with fsmonitor · 0bec70c1
      Katsunori FUJIWARA authored
      Repository cloned-bookmark-default and tobundle exist in the working
      directory of main test repository "repo". We should take care for
      them, because it is known issue that fsmonitor can't handle nested
      repositories.
      
      These nested repositories are cloned from "repo", and the number of
      unknown files = files in these repositories (including files under
      .hg) will be changed easily in the future. But testing with fsmonitor
      is not ordinary.
      
      Therefore, test-bookmarks.t with fsmonitor might be broken silently.
      
      This is reason why this patch uses "(glob)" for the number of unknown
      files in "hg summary" output.
      
      BTW, this patch doesn't use .hgignore to make test portable, because
      .hgignore might cause another issue related to "walk_on_invalidate"
      configuration of fsmonitor.
      0bec70c1
    • Katsunori FUJIWARA's avatar
      tests: add fsmonitor specific output lines at enabling largefiles · fe0667cc
      Katsunori FUJIWARA authored
      Temporarily enabling largefiles causes these output lines, only if
      tests are executed with fsmonitor.
      fe0667cc
  5. Jul 04, 2017
  6. Jun 23, 2017
    • Pierre-Yves David's avatar
      revlog: add an experimental option to mitigated delta issues (issue5480) · 895ecec3
      Pierre-Yves David authored
      The general delta heuristic to select a delta do not scale with the number of
      branch. The delta base is frequently too far away to be able to reuse a chain
      according to the "distance" criteria. This leads to insertion of larger delta (or
      even full text) that themselves push the bases for the next delta further away
      leading to more large deltas and full texts. This full text and frequent
      recomputation throw Mercurial performance in disarray.
      
      For example of a slightly large repository
      
        280 000 files (2 150 000 versions)
        430 000 changesets (10 000 topological heads)
      
      Number below compares repository with and without the distance criteria:
      
      manifest size:
          with:    21.4 GB
          without:  0.3 GB
      
      store size:
          with:    28.7 GB
          without   7.4 GB
      
      bundle last 15 00 revisions:
          with:    800 seconds
                   971 MB
          without:  50 seconds
                    73 MB
      
      unbundle time (of the last 15K revisions):
          with:    1150 seconds (~19 minutes)
          without:   35 seconds
      
      Similar issues has been observed in other repositories.
      
      
      Adding a new option or "feature" on stable is uncommon. However, given that this
      issues is making Mercurial practically unusable, I'm exceptionally targeting
      this patch for stable.
      
      What is actually needed is a full rework of the delta building and reading
      logic. However, that will be a longer process and churn not suitable for stable.
      
      In the meantime, we introduces a quick and dirty mitigation of this in the
      'experimental' config space. The new option introduces a way to set the maximum
      amount of memory usable to store a diff in memory. This extend the ability for
      Mercurial to create chains without removing all safe guard regarding memory
      access. The option should be phased out when core has a more proper solution
      available.
      
      Setting the limit to '0' remove all limits, setting it to '-1' use the default
      limit (textsize x 4).
      895ecec3
  7. Jul 02, 2017
  8. Jun 30, 2017
  9. Jul 02, 2017
    • Gregory Szorc's avatar
      show: implement "stack" view · c5a07a3a
      Gregory Szorc authored
      People often want to know what they are working on *now*. As part of
      this, they also commonly want to know how that work is related to other
      changesets in the repo so they can perform common actions like rebase,
      histedit, and merge.
      
      `hg show work` made headway into this space. However, it is geared
      towards a complete repo view as opposed to just the current line of
      work. If you have a lot of in-flight work or the repo has many heads,
      the output can be overwhelming. The closest thing Mercurial has to
      "show me the current thing I'm working on" that doesn't require custom
      revsets is `hg qseries`. And this requires MQ, which completely changes
      workflows and repository behavior and has horrible performance on large
      repos. But as sub-optimal as MQ is, it does some things right, such as
      expose a model of the repo that is easy for people to reason about.
      This simplicity is why I think a lot of people prefer to use MQ, despite
      its shortcomings.
      
      One common development workflow is to author a series of linear
      changesets, using bookmarks, branches, anonymous heads, or even topics
      (3rd party extension). I'll call this a "stack." You periodically
      rewrite history in place (using `hg histedit`) and reparent the stack
      against newer changesets (using `hg rebase`). This workflow can be
      difficult because there is no obvious way to quickly see the current
      "stack" nor its relation to other changesets. Figuring out arguments to
      `hg rebase` can be difficult and may require highlighting and pasting
      multiple changeset nodes to construct a command.
      
      The goal of this commit is to make stack based workflows simpler
      by exposing a view of the current stack and its relationship to
      other releant changesets, notably the parent of the base changeset
      in the stack and newer heads that the stack could be rebased or merged
      into.
      
      Introduced is the `hg show stack` view. Essentially, it finds all
      mutable changesets from the working directory revision in both
      directions, stopping at a merge or branch point. This limits the
      revisions to a DAG linear range.
      
      The stack is rendered as a concise list of changesets. Alongside the
      stack is a visualization of the DAG, similar to `hg log -G`.
      
      Newer public heads from the branch point of the stack are rendered
      above the stack. The presence of these heads helps people understand
      the DAG model and the relationship between the stack and changes made
      since the branch point of that stack. If the "rebase" command is
      available, a `hg rebase` command is printed for each head so a user
      can perform a simple copy and paste to perform a rebase.
      
      This view is alpha quality. There are tons of TODOs documented
      inline. But I think it is good enough for a first iteration.
      c5a07a3a
  10. Jun 29, 2017
    • Matt Harbison's avatar
      tests: demonstrate inconsistencies with dirty state in various commands · 439b4d00
      Matt Harbison authored
      Not only is the output of these commands inconsistent with respect to each
      other when a file is deleted, they are internally inconsistent depending upon
      whether the deleted file is in the top level repo or a subrepo.  It seemed
      easier to show the problems, rather than describe them.  The original goal was
      to fix the summary command with respect to deleted files.  I haven't fixed any
      of the other issues yet, in case anybody believes the current subrepo behavior
      is correct.
      
      I think a natural understanding of clean/dirty is that they are two opposite
      values of a single binary repo state.  If `hg update --clean -r .` changes a
      file, then naturally that repo was dirty, and `hg update --check` should have
      blocked it.  Deleted files are special, in that they don't block a commit.  But
      they make the filesystem content not the same as a clean checkout.
      439b4d00
  11. Jul 02, 2017
    • Gregory Szorc's avatar
      check-config: syntax to allow inconsistent config values · 5d8942db
      Gregory Szorc authored
      The ignore regular expression has been updated to detect
      "inconsistent config." If present, we track which configs have
      that set and we suppress the conflicting defaults error for those
      options.
      
      I also added named groups to the regexp to aid readability.
      
      A comment was added to profiling.py to make a desired inconsistent
      value error go away.
      5d8942db
  12. Jun 30, 2017
  13. Jul 01, 2017
  14. Jul 04, 2017
  15. Jun 26, 2017
    • Boris Feld's avatar
      log: add an extension hook-point in changeset_printer · 4ecc6047
      Boris Feld authored
      Extensions sometimes wants to add other information in the default log output
      format (when no templating is used).
      
      Add an empty function named '_exthook' for easing the extension life.
      Extensions will be able to wrap this function and collaborate to display
      additional information.
      
      Exthook is called after displaying troubles and just before displaying the
      files, extra and description.
      
      Add a new test file to test it and not pollute other test files.
      4ecc6047
  16. Jun 27, 2017
  17. Jun 23, 2017
    • Pierre-Yves David's avatar
      revlog: add an experimental option to mitigated delta issues (issue5480) · e9d325cf
      Pierre-Yves David authored
      The general delta heuristic to select a delta do not scale with the number of
      branch. The delta base is frequently too far away to be able to reuse a chain
      according to the "distance" criteria. This leads to insertion of larger delta (or
      even full text) that themselves push the bases for the next delta further away
      leading to more large deltas and full texts. This full text and frequent
      recomputation throw Mercurial performance in disarray.
      
      For example of a slightly large repository
      
        280 000 files (2 150 000 versions)
        430 000 changesets (10 000 topological heads)
      
      Number below compares repository with and without the distance criteria:
      
      manifest size:
          with:    21.4 GB
          without:  0.3 GB
      
      store size:
          with:    28.7 GB
          without   7.4 GB
      
      bundle last 15 00 revisions:
          with:    800 seconds
                   971 MB
          without:  50 seconds
                    73 MB
      
      unbundle time (of the last 15K revisions):
          with:    1150 seconds (~19 minutes)
          without:   35 seconds
      
      Similar issues has been observed in other repositories.
      
      
      Adding a new option or "feature" on stable is uncommon. However, given that this
      issues is making Mercurial practically unusable, I'm exceptionally targeting
      this patch for stable.
      
      What is actually needed is a full rework of the delta building and reading
      logic. However, that will be a longer process and churn not suitable for stable.
      
      In the meantime, we introduces a quick and dirty mitigation of this in the
      'experimental' config space. The new option introduces a way to set the maximum
      amount of memory usable to store a diff in memory. This extend the ability for
      Mercurial to create chains without removing all safe guard regarding memory
      access. The option should be phased out when core has a more proper solution
      available.
      
      Setting the limit to '0' remove all limits, setting it to '-1' use the default
      limit (textsize x 4).
      e9d325cf
  18. Jun 29, 2017
  19. Jun 28, 2017
  20. Jun 26, 2017
    • Gregory Szorc's avatar
      show: config option to register aliases for views · 99ce2f58
      Gregory Szorc authored
      As part of using `hg show` in my daily workflow, I've found it slightly
      annoying to have to type full view names, complete with a space. I've
      locally registered an alias for "swork = show work."
      
      I think others will have this same complaint and could benefit from
      some automation to streamline the creation of aliases. So, this
      commit introduces a config option that allows `hg show` views to be
      automatically aliased using a given prefix. e.g. a value of "s"
      will automatically register "swork" and "sbookmarks." Multiple
      values can be given for ultimate flexibility. This arguably isn't
      needed now. But since we don't register aliases if there will be
      a collision and we're bound to have a collision, it makes sense to
      allow multiple prefixes so specific views can avoid collisions by
      using different prefixes.
      99ce2f58
  21. Jun 18, 2017
  22. Jun 17, 2017
  23. Jun 28, 2017
    • Adam Simpkins's avatar
      tests: more completely restore the environment in syshgenv · 98e2c78e
      Adam Simpkins authored
      Update the syshgenv function to attempt to completely restore the original
      environment, rather than only updating a few specific variables.  run_tests.py
      now generates a shell script that can be used to restore the original
      environment, and syshgenv sources it.
      
      This is a bit more complicated than the previous code, but should do a better
      job of running the system hg in the correct environment.
      
      I've tested it on Linux using python 2.x, but let me know if it causes issues
      in other environments.  I'm not terribly familiar with how the tests get run on
      Windows, for instance, and how the environment needs to be updated there.
      98e2c78e
    • Jun Wu's avatar
      tests: do not use system hg if it does not have "files" command · acfce525
      Jun Wu authored
      Ancient hg does not have "hg files" so test-check-*.t will fail with
      "unknown command 'files'":
      
        $ hg files
        hg: unknown command 'files'
        $ hg --version
        Mercurial Distributed SCM (version 2.6.2)
      
      Test "hg files" and give up using syshg if it does not have "files" command.
      acfce525
  24. Jun 27, 2017
    • Pierre-Yves David's avatar
      rebase: also test abort from pretxnclose error · 22ab4664
      Pierre-Yves David authored
      Different hooks will have different properties so we cover more hooks to catch
      further regressions.
      22ab4664
    • Pierre-Yves David's avatar
      rebase: reinforce testing around precommit hook interrupting a rebase · e7faa4a1
      Pierre-Yves David authored
      Different hooks will have different properties so we cover more hooks to catch
      further regression.
      e7faa4a1
    • Pierre-Yves David's avatar
      rebase: provides test case for (issue5610) · 918e7dcf
      Pierre-Yves David authored
      The 4.2 release introduces a regression regarding the behavior of rebase with
      some hook failures. We add the tests from the bug report from Henrik Stuart to
      our test base to prevent further regression on this.
      918e7dcf
    • Pierre-Yves David's avatar
      rebase: backed out changeset cf8ad0e6c0e4 (issue5610) · a5abaa81
      Pierre-Yves David authored
      Having a single transaction for rebase means the whole transaction gets rolled back
      on error. To work around this a small hack has been added to detect merge
      conflict and commit the work done so far before exiting. This hack works because
      there is nothing transaction related going on during the merge phase.
      
      However, if a hook blocks the rebase to create a changeset, it is too late to commit the
      work done in the transaction before the problematic changeset was created. This
      leads to the whole rebase so far being rolled back. Losing merge resolution and
      other work in the process. (note: rebase state will be fully lost too).
      
      Since issue5610 is a pretty serious regression and the next stable release is a
      couple day away, we are taking the backout route until we can figure out
      something better to do.
      a5abaa81
    • Pierre-Yves David's avatar
      rebase: backed out changeset 2519994d25ca · b63351f6
      Pierre-Yves David authored
      In the process of fixing issue5610 in 4.2.2, we are trying to backout
      cf8ad0e6c0e4. This changeset is making changes that depend on cf8ad0e6c0e4,
      so we need to back it out first.
      
      Since issue5610 is pretty serious regression and the next stable release is a
      couple of days away, we are taking the backout route until we can figure out
      something better to do.
      b63351f6
Loading