Skip to content
Snippets Groups Projects
  1. Nov 20, 2018
  2. Nov 15, 2018
    • Boris Feld's avatar
      checkexec: create destination directory if necessary · bd087497
      Boris Feld authored
      Since 460733327640, a "share" use the cache of the source repository. A side
      effect is that no `.hg/cache` directory exists in the "share" anymore. As a
      result, the checkexec logic can't use it to create its temporary file and have
      to use the working copy for that.
      
      This is suboptimal, it pollutes the working copy and prevents them to keep the
      file around in cache. We do not want to use the cache directory for the share
      target, it might be on a different file system.
      
      So instead, we (try to) create the directory if it is missing. This is a
      simple change that fixes the current behavior regression on stable.
      
      On default, we should probably ensure the proper directories are created when
      initializing the repository. We should also introduce a 'wcache' directory to
      hold cache file related to the working copy. This would clarify the cache
      situation regarding shares.
      
      The tests catch a couple of other affected cases.
      bd087497
    • Yuya Nishihara's avatar
      graft: do not try to skip rev derived from ancestor more than once (issue6024) · 3bc2e550
      Yuya Nishihara authored
      We check 'x in revs' in other cases, so let's do the same.
      
      The test case credits to Tom Prince.
      3bc2e550
  3. Nov 16, 2018
    • Matt Harbison's avatar
      subrepo: print the status line before creating the peer for better diagnostics · 69d4c8c5
      Matt Harbison authored
      I ran into a problem where I tried updating to a different branch, and the
      process appeared to hang.  It turned out that the subrepo revision wasn't
      available locally, and I must have originally cloned it from an `hg serve -S` on
      a machine that currently wasn't serving anything.  It took 2+ minutes to
      timeout, and didn't mention what it was connecting to even then.
      
      There are a couple of other issues in this scenario too.
      
        - The repo is dirty after the failed checkout because the top level repo is
          updated first.  We should probably make 2 passes- top down to pull
          everything needed, and then do an update once everything is in place.
      
        - Something must be reading .hgsubstate from wdir because if the same merge
          command is run after the timeout, a prompt is issued that the local and
          remote subrepo diverged, instead of hanging.  But it lists the local version
          and remote version as having the same hash.
      69d4c8c5
  4. Nov 14, 2018
  5. Nov 02, 2018
  6. Oct 19, 2018
    • Anton Shestakov's avatar
      relnotes: various tweaks for release notes · 683e99f0
      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.
      683e99f0
  7. Nov 01, 2018
  8. Oct 31, 2018
    • Boris Feld's avatar
      changegroup: restore default node ordering (issue6001) · 634b4531
      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
      634b4531
  9. Oct 17, 2018
    • Boris Feld's avatar
      phase: add an archived phase · 49c7b701
      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.
      49c7b701
  10. Oct 22, 2018
  11. Oct 05, 2018
  12. Oct 19, 2018
    • Gregory Szorc's avatar
      exchangev2: support fetching shallow files history · 229d23cd
      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
      229d23cd
    • Gregory Szorc's avatar
      wireprotov2: support exposing linknode of file revisions · abbd0779
      Gregory Szorc authored
      When supporting shallow file storage, clients may fetch file revisions
      by changeset. But they may not readily know which changeset introduced a
      specific file revision. The "linknode" is used to record which changeset
      introduces which file revision.
      
      This commit teaches the "filedata" and "filesdata" wire protocol commands
      to expose the linknode for file revisions. The implementation is likely
      wrong when hidden changesets are in play, since the linknode may refer to
      a hidden changeset. We can deal with this problem later.
      
      Differential Revision: https://phab.mercurial-scm.org/D5167
      abbd0779
  13. Sep 26, 2018
    • Gregory Szorc's avatar
      repository: teach addgroup() to receive data with missing parents · 1b183edb
      Gregory Szorc authored
      The way the narrow extension works today, the server rewrites
      outgoing changegroup data to lie about parents when the parents
      data is missing. It adds the ellipsis flag to the revision so
      it can be recorded as such in the revlog.
      
      In the new wire protocol, such rewriting does not occur on
      the server (at least not yet anyway). Instead, it is up to the
      client to recognize when it has received a revision without its
      parents. This means rewriting will be performed on the client.
      
      Furthermore, the mechanism for storing a shallow revision may
      differ from store to store. For example, the revlog store uses
      the ellipsis flag to denote a revision's parents have been
      rewritten. But a non-revlog store may wish to store things
      differently. And, some stores may not even support receiving
      shallow revision data!
      
      Therefore, it makes sense for the store itself to be making
      decisions about what to do when they receive revision data
      without their parents.
      
      This commit teaches the addgroup() bulk insert method to accept
      a boolean argument that indicates whether the incoming data may
      lack parent revisions. This flag can be set when receiving
      "shallow" data from a remote.
      
      The revlog implementation of this method has been taught to rewrite
      the missing parent(s) to nullid and to add the ellipsis flag to
      the revision when a missing parent is encountered. But it only
      does this if ellipsis flags are enabled on the repo and the
      incoming data is marked as possibly shallow. An error occurs
      otherwise.
      
      Differential Revision: https://phab.mercurial-scm.org/D5165
      1b183edb
  14. Oct 22, 2018
    • Matt Harbison's avatar
      lfs: consult the narrow matcher when extracting pointers from ctx (issue5794) · 4a81d824
      Matt Harbison authored
      I added a testcase for lfs to all narrow tests, and the following failed:
      
          test-narrow-acl.t
          test-narrow-exchange.t
          test-narrow-patterns.t
          test-narrow-strip.t
          test-narrow-trackedcmd.t
          test-narrow-widen.t
          test-narrow.t
      
      The first two still have errors in the pretxnchangegroup on clone and (receiving
      a) push, which I'm still looking into (4d63f3bc1e1a fixed something in this area
      already).  These two modified tests seem to cover the things that failed in the
      remaining narrow tests, i.e. `hg tracked` and `hg strip`, so I didn't bother
      enabling the testcases elsewhere.  Maybe we should, but it's 68 tests total.
      4a81d824
  15. Oct 20, 2018
    • Matt Harbison's avatar
      tests: add coverage for some untested areas of hgweb · bd1ec1e3
      Matt Harbison authored
      The fact that these mimetype guesses weren't blowing up anywhere on py3 prior to
      9310037f0636 was the giveaway.  The annotate function is a bit unusual in that
      it renders the page with a 500 in the middle, so I left the HTML output.  For
      the other functions, checking the access log is enough.
      bd1ec1e3
  16. Oct 19, 2018
  17. Oct 18, 2018
    • Matt Harbison's avatar
      tests: glob over a difference between Windows 7 and Window 10 · 5a81c4aa
      Matt Harbison authored
      The error value is 11001 on Windows 10.  I have no idea why it changed, but it
      seems unimportant.
      5a81c4aa
    • Matt Harbison's avatar
      py3: fix module imports in test-highlight.t · 3b84ef90
      Matt Harbison authored
      The hash changes are because the *.py file is committed to the repo.
      3b84ef90
    • Matt Harbison's avatar
      py3: fix module imports in tests, as flagged by test-check-module-imports.t · ef6cab79
      Matt Harbison authored
      I have no idea why these aren't flagged with python2.  I excluded
      test-highlight.t for now to make this easier to review- the changed code is
      committed to a repo, which has cascading changes on the rest of the test.
      
      There's a mix of bytes and str in the imports dict of contrib/import-checker.py
      that crashed it half way through listing out these errors.  I couldn't figure
      out how to fix that properly, so I was lazy and applied this on py3, to find the
      rest of the errors:
      
          diff --git a/contrib/import-checker.py b/contrib/import-checker.py
          --- a/contrib/import-checker.py
          +++ b/contrib/import-checker.py
          @@ -626,7 +626,12 @@ def find_cycles(imports):
               top.foo -> top.qux -> top.foo
               """
               cycles = set()
          -    for mod in sorted(imports.keys()):
          +    def sort(v):
          +        if isinstance(v, bytes):
          +            return v.decode('ascii')
          +        return v
          +
          +    for mod in sorted(imports.keys(), key=sort):
                   try:
                       checkmod(mod, imports)
                   except CircularImport as e:
      ef6cab79
  18. Oct 19, 2018
  19. Oct 18, 2018
    • Yuya Nishihara's avatar
      addremove: add "ui." prefix to message color keys · 824b687f
      Yuya Nishihara authored
      I don't like fully-colorized status/warning messages, and I want to disable
      them at all. If we'd supported a syntax like 'color.ui.*=none', I could
      easily turn addremove.added/removed off as well as ui.error. This patch is
      just for that.
      
      Since addremove colors aren't released yet, which were added at ddc1da134772,
      there are no compatibility concerns.
      824b687f
  20. Feb 09, 2017
  21. Oct 18, 2018
  22. Oct 16, 2018
Loading