Skip to content
Snippets Groups Projects
  1. Jul 22, 2019
  2. Jul 21, 2019
  3. Jul 20, 2019
  4. Jul 19, 2019
  5. Jul 18, 2019
  6. Jul 21, 2019
  7. Jul 18, 2019
  8. 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
  9. 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
  10. Jul 02, 2019
    • sliquister's avatar
      tests: show the files fields of changelogs for many merges · 20d0e59b
      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
      20d0e59b
  11. Jul 16, 2019
    • Ian Moody's avatar
      phabricator: handle local:commits time being string or int · c17e6a3e
      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
      c17e6a3e
    • Ian Moody's avatar
  12. Jul 02, 2019
  13. Jul 07, 2019
  14. Jul 17, 2019
    • Taapas Agrawal's avatar
      continue: added support for unshelve · 117437f3
      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
      117437f3
  15. Jul 15, 2019
    • Taapas Agrawal's avatar
      continue: added support for rebase · 35ebdbb3
      Taapas Agrawal authored
      This adds support of rebase to hg continue plan.
      
      An independent continue logic for rebase is created
      under continuerebase() function. For this a seperate
      rebaseruntime object is created under the function to
      handle an interrupted rebasestate.
      
      Results of tests are shown.
      
      Differential Revision: https://phab.mercurial-scm.org/D6646
      35ebdbb3
    • Taapas Agrawal's avatar
      continue: added logic for hg continue · 3c16b9c0
      Taapas Agrawal authored
      This is part of GSoC19 project `Implement abort and
      continue commands`. This patch is part of the continue plan.
      
      This adds the basic logic for hg continue. This command
      aborts an multistep operation like graft, histedit, rebase,
      transplant and unshelve if they are in an unfinished state.
      
      The first part of the logic is determining the unfinished
      operation from the state detection API under statemod.
      This API is extended to support hg continue by adding a method
      to register the abort logic as a function (here continuefunc).
      
      Once the unfinished operation is determined the registered
      logic is used to resume the command in case it is interrupted.
      The benefit of this kind of framework is that any new extension
      developed can support hg continue by registering the command
      and logic under statedetection API.
      
      hg continue currently supports --dry-run/-n flag only.
      It is used to dry run hg abort
      
      Differential Revision: https://phab.mercurial-scm.org/D6645
      3c16b9c0
  16. Jul 17, 2019
  17. Jul 10, 2019
  18. Jul 02, 2019
    • Raphaël Gomès's avatar
      rust: switch hg-core and hg-cpython to rust 2018 edition · 326fdce2
      Raphaël Gomès authored
      Many interesting changes have happened in Rust since the Oxidation Plan was
      introduced, like the 2018 edition and procedural macros:
      
          - Opting in to the 2018 edition is a clear benefit in terms of future
            proofing, new (nice to have) syntactical sugar notwithstanding. It
            also has a new non-lexical, non-AST based borrow checker that has
            fewer bugs(!) and allows us to write correct code that in some cases
            would have been rejected by the old one.
          - Procedural macros allow us to use the PyO3 crate which maintainers have
            expressed the clear goal of compiling on stable, which would help in
            code maintainability compared to rust-cpython.
      
      In this patch are the following changes:
          - Removing most `extern crate` uses
          - Updating `use` clauses (`crate` keyword, nested `use`)
          - Removing `mod.rs` in favor of an aptly named module file
      
      Like discussed in the mailing list (
      https://www.mercurial-scm.org/pipermail/mercurial-devel/2019-July/132316.html
      ), until Rust integration in Mercurial is considered to be out of the
      experimental phase, the maximum version of Rust allowed is whatever the latest
      version Debian packages.
      
      Differential Revision: https://phab.mercurial-scm.org/D6597
      326fdce2
  19. Jul 12, 2019
  20. Jul 16, 2019
  21. Jul 15, 2019
  22. Jul 12, 2019
  23. Jul 10, 2019
  24. Jul 13, 2019
    • Martin von Zweigbergk's avatar
      py3: source-transform only call-sites of iteritems(), not definitions · 3018749a
      Martin von Zweigbergk authored
      branchmap.branchcache, among other classes, defines a
      iteritems(). That currently gets replaced by items() by the source
      transformer. That makes it harder for extensions to work with both py2
      and py3, since they have to call either items() or iteritems() on
      branchcache. Let's not replace definitions of iteritems() (and
      itervalues()) and only replace the call-sites. We need to also add an
      items() alias to branchcache (etc) so our transformer call-sites will
      find it.
      
      Differential Revision: https://phab.mercurial-scm.org/D6641
      3018749a
  25. Jul 15, 2019
  26. Jul 14, 2019
  27. Jun 29, 2019
    • Taapas Agrawal's avatar
      abort: added support for merge · 3bc400cc
      Taapas Agrawal authored
      This adds support of `hg merge --abort` to `hg abort` plan.
      
      This involves refactoring `hg.merge` into two different
      functions removing the abort logic of `merge` from `hg.merge`
      and then creating a seperate `hg.abortmerge` to handle the
      abort logic so that the abortion of merge can be called
      independently.
      
      `hg.abortmerge` is then registered as `abortfunc` for the
      state detection API so that `commands.abort` can use it to
      deal with an unfinished merge operation.
      
      Results are shown as tests.
      
      Differential Revision: https://phab.mercurial-scm.org/D6588
      3bc400cc
Loading