Skip to content
Snippets Groups Projects
  1. Aug 01, 2019
    • Martin von Zweigbergk's avatar
      relnotes: copy "next" to "5.1" and clear "next" · cba59b33
      Martin von Zweigbergk authored
      To avoid merge conflicts, we want to avoid modifying the file on
      multiple branches in parallel. This patch is therefore meant to be
      applied to the stable branch and then quickly be merged to default (at
      least before edits are made to relnotes/next there).
      
      Another option would have been to copy the file on the stable branch
      and to clear it on the default branch. However, that still results in
      conflicts if the copy is edited on the stable branch (Mercurial would
      try to apply the changes from the default branch to it).
      
      We could also delete the file in one commit and recreate it in another
      commit. However, Mercurial is quite inconsistent in what it considers
      a break in history (see test-copies-unrelated.t), so I'd like to avoid
      that.
      
      Differential Revision: https://phab.mercurial-scm.org/D6705
      cba59b33
  2. Aug 03, 2019
    • Gregory Szorc's avatar
      automation: push changes affecting .hgtags · 9e0f1c80
      Gregory Szorc authored
      When I went to build the 5.1 tag using the in-repo automation, the
      automatic version calculation failed to deduce the clean 5.1 version
      string because we had only pushed the changeset corresponding to the 5.1
      tag and not the changeset containing the 5.1 tag. So from the
      perspective of the remote repo, the 5.1 tag didn't exist yet and
      automatic version deduction failed.
      
      This commit changes the `hg push` to also push all changesets affecting
      the .hgtags file, ensuring the remote has up-to-date tags information.
      
      I tested this by creating a local draft changeset with a dummy tag
      value on a different DAG head and instructed the automation to build
      a revision that didn't have this change to .hgtags. The tag was
      successfully pushed and the built package had a version number
      incorporating that tag.
      
      Sending this to stable so the 5.1.1 automation hopefully "just works."
      9e0f1c80
  3. Jun 21, 2019
    • Pierre-Yves David's avatar
      bookmarks: actual fix for race condition deleting bookmark · e0cf09bc
      Pierre-Yves David authored
      This is a simple but efficient fix to prevent the issue tested in
      `test-bookmarks-corner-case.t`. It might be worth pursuing a more generic
      approach where filecache learn to depend on each other, but that would not be
      suitable for stable.
      
      The issue is complicated enough that I documented the race and its current
      solution as inline comment. See this comment for details on the fix.
      e0cf09bc
  4. Aug 01, 2019
  5. Jul 29, 2019
    • Gregory Szorc's avatar
      automation: execute powershell when connecting · e91930d7
      Gregory Szorc authored
      For some reason, the ability to execute PS scripts appears to
      come online after the ability to execute regular command scripts.
      This is creating race conditions when connecting to instances
      resulting in our wait_for_winrm() returning before PS is available
      leading to an exception being thrown in other code.
      
      Let's change the client connection code to execute a minimal
      PS script so we can try to trap the exception in wait_for_winrm().
    • Gregory Szorc's avatar
      automation: allow exit code of 1 for `hg push` · 24cd5b0b
      Gregory Szorc authored
      `hg push` exits 1 for no-ops. No-op pushes should be fine in the
      context of automation.
      24cd5b0b
  6. Jul 25, 2019
  7. Jul 23, 2019
  8. Jul 22, 2019
  9. Jul 21, 2019
  10. Jul 20, 2019
  11. Jul 19, 2019
  12. Jul 18, 2019
  13. Jul 21, 2019
  14. Jul 18, 2019
  15. Jul 02, 2019
    • sliquister's avatar
      commit: improve the files field of changelog for merges · 99ebde4f
      sliquister authored
      Currently, the files list of merge commits repeats all the deletions
      (either actual deletions, or files that got renamed) that happened
      between base and p2 of the merge. If p2 is the main branch, the list
      can easily be much bigger than the change being merged.
      
      This results in various problems worth improving:
      - changelog is bigger than necessary
      - `hg log directory` lists many unrelated merge commits, and `hg log
        -v -r commit` frequently fills multiple screens worth of files
      - it possibly slows down adjustlinkrev, by forcing it to read more
        manifests, and that function can certainly be a bottleneck
      - the server side of pulls can waste a lot of time simply opening the
        filelogs for pointless files (the constant factors for opening even
        a tiny filelog is apparently pretty bad)
      
      So stop listing such files as described in the code.  Impacted merge
      commits and their descendants get a different hash than they would
      have without this. This doesn't seem problematic, except for
      convert. The previous commit helped with that in the hg->hg case (but
      if you do svn->hg twice from scratch, hashes can still change).
      
      The rest of the description is numbers. I don't have much to report,
      because recreating the files list of existing repositories is not
      easy:
      - debugupgradeformat and bundle/unbundle don't recreate the list
      - export/import tends to choke quickly applying patches or on
        description that contain diffs,
      - merge commits from the convert extension don't have the right files
        list for reasons orthogonal to the current commit
      - replaying the merge with hg update/hg merge/hg revert --all/hg
        commit can end up failing in hg revert
      - I wasn't sure that using debugsetparents + debugrebuilddirstate
        would really build the right thing
      
      I measured commit time before and after this change, in a case with no
      files filtered out, several files filtered out (no difference) and 5k
      files filtered out (+1% time).
      
      Recreating the 100 more recent merges in a private repo, the
      concatenated uncompressed files lists goes from 1.12MB to
      0.52MB. Excluding 3 merges that are not representative, then the size
      goes from 570k to 15k.
      I converted part of mozilla-central, and observed file list shrinking
      quite a bit too, starting at the very first merge, 733641d9feaf, going
      from 550 files to 10 files (although they have relatively few merges,
      so they probably wouldn't care).
      
      Differential Revision: https://phab.mercurial-scm.org/D6613
      99ebde4f
  16. Jul 14, 2019
    • sliquister's avatar
      convert: add a config option to help doing identity hg->hg conversion · d98ec36b
      sliquister authored
      I want to change the computation of the list of files modified by a
      commit. In principle, this would simply change a cache. But since this
      information is stored in commits rather than a cache, changing it
      means changing commit hashes (going forward).
      
      Some users rely on the convert extension from hg to hg not changing
      hashes when nothing changes (usually). Allow these users to preserve
      hashes despite changes to the changelog files computation by reusing
      these files lists when the manifest is unchanged (since these files
      list are derived from the manifest).
      
      Differential Revision: https://phab.mercurial-scm.org/D6643
      d98ec36b
Loading