Skip to content
Snippets Groups Projects
  1. Aug 01, 2019
  2. Jul 29, 2019
    • Gregory Szorc's avatar
      automation: execute powershell when connecting · e91930d712e8
      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().
      5.1
      e91930d712e8
    • Gregory Szorc's avatar
      automation: allow exit code of 1 for `hg push` · 24cd5b0ba5b3
      Gregory Szorc authored
      `hg push` exits 1 for no-ops. No-op pushes should be fine in the
      context of automation.
      24cd5b0ba5b3
  3. Jul 25, 2019
  4. Jul 23, 2019
  5. Jul 22, 2019
  6. Jul 21, 2019
  7. Jul 20, 2019
  8. Jul 19, 2019
  9. Jul 18, 2019
  10. Jul 21, 2019
  11. Jul 18, 2019
  12. Jul 02, 2019
    • sliquister's avatar
      commit: improve the files field of changelog for merges · 99ebde4fec99
      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
      99ebde4fec99
  13. Jul 14, 2019
    • sliquister's avatar
      convert: add a config option to help doing identity hg->hg conversion · d98ec36be808
      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
      d98ec36be808
  14. Jul 02, 2019
    • sliquister's avatar
      tests: show the files fields of changelogs for many merges · 20d0e59be79b
      sliquister authored
      I don't think there's coverage for many of the subtle cases, and I
      found it hard to understand what the code is doing by reading it.  The
      test takes 40s to run on a laptop, or 9s with --chg.
      
      I have yet to find a description of what the files field is supposed
      to be for merges. I thought it could be one of:
      1. the files added/modified/removed relative to p1 (wouldn't seem
        useful, but `hg diff -c -r mergerev` has this behavior)
      2. the files with filelog nodes not in either parent (i.e., what is
      needed to create a bundle out of a commit)
      3. the files added/removed/modified files by merge itself [1]
      
      It's clearly not 1, because file contents merges are symmetric. It's
      clearly not 2 because removed files and exec bit changes are
      listed. It's also not 3 but I think it's intended to be 3 and the
      differences are bugs.
      
      Assuming 3, the test shows that, for merges, the list of files both
      overapproximates and underapproximates. All the cases involve file
      changes not in the filelog but in the manifest (existence of file
      at revision, exec bit and file vs symlink).
      
      I didn't look at all underapproximations, but they looked minor. The
      two overapproximations are problematic though because they both cause
      potentially long lists of files when merging cleanly.
      
      
      [1] even what it means for the merge commit itself to change a file is
      not completely trivial. A file in the merge being the same as in one
      of the parent is too lax as it would consider that merges change
      nothing when they revert all the changes done on one side. The
      criteria used in the test and in the next commit for "merge didn't
      touch a file" is:
      - the parents and the merge all have the same file
      - or, one parent didn't touch the file and the other parent contains
        the same file as the merge
      
      Differential Revision: https://phab.mercurial-scm.org/D6612
      20d0e59be79b
  15. Jul 16, 2019
    • Ian Moody's avatar
      phabricator: handle local:commits time being string or int · c17e6a3e7356
      Ian Moody authored
      When setting local:commits arcanist has different behaviour depending on
      whether the repo is git or hg. With hg it sets the time as a number, since it
      calls PHP's strtotime on the value, but with git it sets it as a string.
      Normally this wouldn't be an issue since phabread wouldn't be interacting with
      Phabricator Revisions for git repos, but Mozilla has a secondary workflow for
      git users that uses the git-cinnabar tool to interact with their hg repos. When
      a git-cinnabar user uses the moz-phab tool to submit patches for mozilla-central
      it makes use of Mozilla's fork of arcanist, which works with their local git
      version of m-c, and thus sets the local:commit time as a string, and then
      translates the commit hashes.
      
      Currently when encountering such DREVS phabread dies with "TypeError: %d format:
      a number is required, not str".
      
      phabsend also used to set it as a string but wouldn't have encountered the
      issue with its own DREVs since it would read hg:meta first.
      
      Differential Revision: https://phab.mercurial-scm.org/D6650
      c17e6a3e7356
    • Ian Moody's avatar
  16. Jul 02, 2019
  17. Jul 07, 2019
  18. Jul 17, 2019
    • Taapas Agrawal's avatar
      continue: added support for unshelve · 117437f3f541
      Taapas Agrawal authored
      This patch adds the support for `ushelve` in `hg continue` plan.
      
      `hgcontinueunshelve()` has been created for independent calls.
      In case an interrupted unshelve is resumed via hg continue the
      shelvedstate needs to be loaded seperately. This has been
      ensured by `_loadunshelvedstate()`
      
      `hgcontinueunshelve()` is then registered as `continuefunc` for state
      detection API.
      
      Results are shown as tests.
      
      Differential Revision: https://phab.mercurial-scm.org/D6652
      117437f3f541
Loading