Skip to content
Snippets Groups Projects
  1. Nov 02, 2018
  2. Oct 28, 2018
  3. Nov 02, 2018
  4. Oct 19, 2018
    • Anton Shestakov's avatar
      relnotes: various tweaks for release notes · 683e99f0b30c
      Anton Shestakov authored
      Stop filtering out commits that are expected to be covered by releasenotes
      extension: now we want two lists, one for WhatsNew and one for ReleaseX.Y.
      
      Use `only(stoprev, startrev)` to make `relnotes -h` output be actually true
      about what revisions are included.
      
      More filter rules, mostly obvious.
      
      More classifying rules to have less things in "unsorted".
      
      Looks like nargs=1 was just making args.startrev and args.stoprev be lists for
      no reason.
      
      BC and API sections are renamed to what we're using on the WhatsNew page, and
      also just skipped if empty.
      683e99f0b30c
  5. Nov 01, 2018
  6. Oct 31, 2018
    • Paul Morelle's avatar
      setup: explain to distutils how we write rc versions · b6bc2293cdf3
      Paul Morelle authored
      When we use a rc version number (e.g. 4.8rc0), bdist_msi is using
      distutils.StrictVersion to parse it into a tuple of numbers.
      By default, StrictVersion.version_re only recognizes [ab] for alpha/beta,
      where mercurial may use '-rc' or 'rc'.
      This change makes StrictVersion parse correctly our version numbers, so that
      bdist_msi doesn't fail on rc versions.
      b6bc2293cdf3
    • Boris Feld's avatar
      changegroup: restore default node ordering (issue6001) · 634b45317459
      Boris Feld authored
      Changeset db5501d93bcf changed the default node ordering from "storage" to
      "linearize".
      
      While the new API is more explicit and cleaner, the "linearize" order is
      problematic on certain repositories like netbeans where it makes bundling
      slower the more nodes we bundle.
      
      Pushing and pulling 100 changesets was ~20% slower and pushing and pulling
      1000 changesets was ~600% slower.
      
      A very quick analysis of profile traces showed that the pull operation was
      taking more time creating the delta.
      
      Putting back the old default order seems to be the safe option. With more time
      during the next cycle, we can understand better the impact of sorting with the
      DAG order by default, the source of the regression and how to mitigate it.
      
      /!\ We are still waiting for the full performance impact but with this patch,
      bundling and pulling locally (not on the performance workstation) 1000
      changesets on the netbeans repository is as fast as before the regression.
      
      Differential Revision: https://phab.mercurial-scm.org/D5196
      634b45317459
  7. Oct 29, 2018
  8. Oct 31, 2018
    • Yuya Nishihara's avatar
      fix: disable use of thread-based worker · 8ebb05f747e5
      Yuya Nishihara authored
      getfixes() accesses to repo, changectx, filectx, etc., so I believe there
      are code paths triggering data race. Mercurial API isn't thread safe in
      general.
      8ebb05f747e5
    • Pulkit Goyal's avatar
      configitems: rename the config to prevent adding an alias in future · 14b6afc6cb28
      Pulkit Goyal authored
      Right now the config option looks like:
      
      [experimental.server]
      stream-narrow-clones=
      
      which does not match how config options are generally defined in core. So let's
      rename this to:
      
      [experimental]
      server.stream-narrow-clones=
      
      before the new release so that we don't have to add an alias in future for this.
      
      Differential Revision: https://phab.mercurial-scm.org/D5198
      14b6afc6cb28
    • Boris Feld's avatar
      sparse-revlog: only refine delta candidates in the sparse case (issue6006) · bafa1c4bb7a8
      Boris Feld authored
      Starting with 5aef5afa8654, a valid delta parent might be "refined". This
      allows repository using sparse-revlog to produce better delta chain by using
      better intermediate snapshot base.
      
      However, this refining step was performed in all cases, including for
      repository not using sparse-revlog. This could produce a strange chain in the
      general delta case and corrupted repository in the non-general delta case.
      
      We now skip this step unless sparse-revlog is in use.
      
      In issue 6006, Yuya Nishihara provided a test case using an external
      repository, so we did not include it. Finding "laboratory" condition to
      reproduce this case and implementing an efficient test reproducing it is a bit
      tricky. We do not foresee to have the time to provide one by the release date.
      
      Differential Revision: https://phab.mercurial-scm.org/D5197
      bafa1c4bb7a8
  9. Oct 29, 2018
    • Augie Fackler's avatar
      http: work around custom http client classes that refuse extra attrs · 588f1e9a4d16
      Augie Fackler authored
      I have no idea what is going on with our custom http client code at Google,
      but it chokes on these extra attributes we're tucking on http clients. Since
      it feels more than a little wrong to just stuff extra data on a client, let's
      degrade gracefully when the client class refuses the attributes.
      588f1e9a4d16
  10. Oct 25, 2018
  11. Oct 24, 2018
  12. Oct 25, 2018
  13. Oct 17, 2018
    • Boris Feld's avatar
      phase: add an archived phase · 49c7b701fdc2
      Boris Feld authored
      This phase allows for hidden changesets in the "user space". It differs from
      the "internal" phase which is intended for internal by-product only. There
      have been discussions at the 4.8 sprint to use such phase to speedup cleanup
      after history rewriting operation.
      
      Shipping it in the same release as the 'internal-phase' groups the associated
      `requires` entry. The important bit is to have support for this phase in the
      earliest version of mercurial possible. Adding the UI to manipulate this new
      phase later seems fine.
      
      The current plan for archived usage and user interface are as follow. On a
      repository with internal-phase on and evolution off:
      
      * history rewriting command set rewritten changeset in the archived phase.
        (This mean updating the cleanupnodes method).
      * keep `hg unbundle .hg/strip-backup/X.hg` as a way to restore changeset for
        now
        (backup bundle need to contains phase data)
      * [maybe] add a `hg strip --soft` advance flag
        (a light way to expose the feature without getting in the way of a better
        UI)
      
      Mercurial 4.8 freeze is too close to get the above in by then.
      
      We don't introduce a new repository `requirement` as we reuse the one
      introduced with the 'archived' phase during the 4.8 cycle.
      49c7b701fdc2
  14. Oct 23, 2018
  15. Oct 22, 2018
  16. Aug 17, 2018
    • Boris Feld's avatar
      profiling: move default mode to "real" time · db0dba2d157d
      Boris Feld authored
      Mercurial operations involve a lot of disks or network access. These impact
      command runtime significantly and it seems important to report them in our
      default profiling output.
      
      Having the right default means that we don't forget them when asking people to
      produces profiling traces or when doing profiling ourselves.
      
      Moving to "real time" by default will remove the need to think about
      activating it on most occasions. The "CPU" time-based profiling is still
      accessible when necessary.
      db0dba2d157d
  17. Oct 05, 2018
  18. Oct 19, 2018
  19. Oct 18, 2018
  20. Oct 19, 2018
    • Gregory Szorc's avatar
      exchangev2: support fetching shallow files history · 229d23cdb203
      Gregory Szorc authored
      This commit teaches the exchangev2 client code to handle fetching shallow
      files data.
      
      Only shallow fetching of files data is supported: shallow fetching of
      changeset and manifest data is explicitly not yet supported.
      
      Previously, we would fetch file revisions for changesets that were received
      by the current pull operation. In the new model, we calculate the set of
      "relevant" changesets given the pull depth and only fetch files data for
      those changesets.
      
      We also teach the "filesdata" command invocation to vary parameters as needed.
      
      The implementation here is far from complete or optimal. Subsequent pulls will
      end up re-fetching a lot of files data. But the application of this data should
      mostly be a no-op on the client, so it isn't a big deal.
      
      Depending on the order file revisions are fetched in, revisions could get
      inserted with the wrong revision number relationships. I think the best way
      to deal with this is to remove revision numbers from storage and to either
      dynamically derive them (by reconstructing a DAG from nodes/parents) or remove
      revision numbers from the file storage interface completely.
      
      A missing API that we'll likely want to write pretty soon is "ensure files
      for revision(s) are present." We can kind of cajole exchangev2.pull() to do
      this. But it isn't very efficient. For example, in simple cases like
      widening the store to obtain data for a single revision, it is probably
      more efficient to walk the manifest and find exactly which file revisions
      are missing and to make explicit requests for just their data. In more
      advanced cases, asking the server for all files data may be more efficient,
      even though it requires sending data the client already has. There is tons
      of room for future experimentation here. And TBH I'm not sure what the
      final state will be.
      
      Anyway, this commit gets us pretty close to being able to have shallow
      and narrow checkouts with exchangev2/sqlite storage. Close enough that a
      minimal extension should be able to provide fill in the gaps until the code
      in core stabilizes and there is a user-facing way to trigger the
      narrow/shallow bits from `hg clone` without also implying using of the
      narrow extension...
      
      Differential Revision: https://phab.mercurial-scm.org/D5169
      229d23cdb203
  21. Oct 17, 2018
    • Gregory Szorc's avatar
      sqlitestore: support for storing revisions without their parents · 595641bd8404
      Gregory Szorc authored
      This commit kinda/sorta implements the equivalent of ellipsis nodes for
      the SQLite storage backend.
      
      Without implementing full blown ellipsis nodes (and the necessary support for
      them in the wire protocol), we instead teach the store to rewrite the p1 and
      p2 nodes to nullid when the incoming parent isn't in the local store. This allows
      servers to remain dumb and send the real parent and have the clients deal
      with the missing parent problem.
      
      This obviously isn't ideal because a benefit of ellipsis nodes is we can
      insert a fake parent to ellide missing changesets. But neither solution is
      ideal because it drops the original parent from storage. We could probably
      teach the SQLite store to retain the original parent and handle missing
      parents at read time. However, parent revisions are stored as integers and
      it isn't trivial to store an "empty" revision in the store yet, which would
      be necessary to represent the "missing" parent.
      
      The store is somewhat intelligent in trying to remove the missing parents
      metadata when the revision is re-added. But, revision numbers will be all
      messed up in that case, so I'm not sure it is worth it. At some point we'll
      likely want to remove the concept of revision numbers from the database and
      have the store invent them at index generation time. Or even better, we can
      do away with revision numbers from the file storage interface completely.
      We'll get there eventually...
      
      Differential Revision: https://phab.mercurial-scm.org/D5168
      595641bd8404
Loading