Skip to content
Snippets Groups Projects
  1. Jul 02, 2017
  2. Jun 30, 2017
  3. Jul 03, 2017
    • Jun Wu's avatar
      phabricator: add phabread command to read patches · 04cf9927
      Jun Wu authored
      This patch adds a `phabread` command generating plain-text patches from
      Phabricator, suitable for `hg import`. It respects `hg:meta` so user and
      date information might be preserved. And it removes `Summary:` field name
      which makes the commit message a bit tidier.
      
      To support stacked diffs, a `--stack` flag was added to read dependent
      patches recursively.
      04cf9927
    • Jun Wu's avatar
      phabricator: add phabsend command to send a stack · 228ad1e5
      Jun Wu authored
      The `phabsend` command is intended to provide `hg email`-like experience -
      sending a stack, setup dependency information and do not amend existing
      changesets.
      
      It uses differential.createrawdiff and differential.revision.edit Conduit
      API to create or update a Differential Revision.
      
      Local tags like `D123` are written indicating certain changesets were sent
      to Phabricator. The `phabsend` command will use obsstore and tags
      information to decide whether to update or create Differential Revisions.
      228ad1e5
    • Jun Wu's avatar
      phabricator: add a contrib script · 36b3febd
      Jun Wu authored
      The default Phabricator client arcanist is not friendly to send a stack of
      changesets. It works better when a feature branch is reviewed as a single
      review unit. However, we want multiple revisions per feature branch.
      
      To be able to have an `hg email`-like UX to send and receive a stack of
      commits easily, it seems we have to re-invent things. This patch adds
      `phabricator.py` speaking Conduit API [1] in `contrib` as the first step.
      This may also be an option for people who don't want to run PHP.
      
      Config could be done in `hgrc` (instead of `arcrc` or `arcconfig`):
      
          [phabricator]
          # API token. Get it from https://phab.mercurial-scm.org/conduit/login/
          token = cli-xxxxxxxxxxxxxxxxxxxxxxxxxxxx
          url = https://phab.mercurial-scm.org/
          # callsign is used by the next patch
          callsign = HG
      
      This patch only adds a single command: `debugcallconduit` to keep the patch
      size small. To test it, having the above config, and run:
      
          $ hg debugcallconduit diffusion.repository.search <<EOF
          > {"constraints": {"callsigns": ["HG"]}}
          > EOF
      
      The result will be printed in prettified JSON format.
      
      [1]: Conduit APIs are listed at https://phab.mercurial-scm.org/conduit/
      36b3febd
  4. 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
  5. 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
  6. 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
  7. Jun 30, 2017
  8. Jul 01, 2017
  9. Jun 30, 2017
  10. Jun 28, 2017
  11. Jun 30, 2017
  12. Jul 01, 2017
  13. Jun 29, 2017
  14. Jul 02, 2017
  15. Jul 01, 2017
  16. Jun 25, 2017
    • Gregory Szorc's avatar
      revlog: C implementation of delta chain resolution · 6d678ab1
      Gregory Szorc authored
      I've seen revlog._deltachain() appear in a number of performance
      profiles. I suspect there are 2 reasons for this:
      
      1. Delta chain resolution performs many index lookups, thus triggering
         population of index tuples. Creating possibly tens of thousands of
         PyObject will have overhead.
      2. Delta chain resolution is a tight loop.
      
      By moving delta chain resolution to C, we can defer instantiation
      of full index entry tuples and make the loop faster courtesy of
      not running in Python.
      
      We can measure the impact to delta chain resolution via
      `hg perflogrevision` using the mozilla-central repo with a recent
      manifest having delta chain length of 33726:
      
      $ hg perfrevlogrevision -m 364895
      ! full
      ! wall 0.367585 comb 0.370000 user 0.340000 sys 0.030000 (best of 27)
      ! wall 0.357581 comb 0.360000 user 0.350000 sys 0.010000 (best of 28)
      ! deltachain
      ! wall 0.010644 comb 0.010000 user 0.010000 sys 0.000000 (best of 270)
      ! wall 0.000292 comb 0.000000 user 0.000000 sys 0.000000 (best of 8729)
      
      $ hg perfrevlogrevision --cache -m 364895
      ! deltachain
      ! wall 0.003904 comb 0.000000 user 0.000000 sys 0.000000 (best of 712)
      ! wall 0.000284 comb 0.000000 user 0.000000 sys 0.000000 (best of 9926)
      
      The first test measures savings from both not instantiating index
      entries and moving to C. The second test (which doesn't clear the
      index caches) essentially isolates the benefits of moving from Python
      to C. It still shows a 13.7x speedup (versus 36.4x). And there are
      multiple milliseconds of savings within the critical path for resolving
      revision data. I think that justifies the existence of C code.
      
      A more striking example of the benefits of this change can be
      demonstrated by timing `hg debugdeltachain -m` for the mozilla-central
      repo:
      
      $ time hg debugdeltachain -m > /dev/null
      before:        1057.4s
      after:          503.3s
      PyPy2.7 5.8.0:  220.0s
      
      It's worth noting that the C code isn't as optimal as it could be.
      We're still instantiating a new PyObject for every revision. A future
      optimization would be to reuse the PyObject on the cached index tuple.
      We could potentially also get wins by using a memory array of raw
      integers. There is also room for a delta chain cache on revlog
      instances. Of course, the best optimization is to implement revlog
      reading outside of Python so Python doesn't need to be concerned
      about the relatively expensive index entries and operations on them.
      6d678ab1
  17. Jun 28, 2017
Loading