Skip to content
Snippets Groups Projects
  1. Feb 22, 2025
  2. Nov 30, 2024
  3. Oct 17, 2024
  4. Sep 24, 2024
  5. Dec 11, 2023
    • Pierre-Yves David's avatar
      changelog: never inline changelog · dcaa2df1f688
      Pierre-Yves David authored
      The test suite mostly use small repositories, that implies that most changelog in the
      tests are inlined. As a result, non-inlined changelog are quite poorly tested.
      Since non-inline changelog are most common case for serious repositories, this
      lack of testing is a significant problem that results in high profile issue like
      the one recently fixed by 66417f55ea33 and 849745d7da89.
      
      Inlining the changelog does not bring much to the table, the number of total
      file saved is negligible, and the changelog will be read by most operation
      anyway.
      
      So this changeset is make it so we never inline the changelog, and de-inline the
      one that are still inlined whenever we touch them.
      
      By doing that, we remove the "dual code path" situation for writing new entry to
      the changelog and move to a "single code path" situation. Having a single
      code path simplify the code and make sure it is covered by test (if test cover
      that situation obviously)
      
      
      This impact all tests that care about the number of file and the exchange size,
      but there is nothing too complicated in them just a lot of churn.
      
      The churn is made "worse" by the fact rust will use the persistent nodemap on
      any changelog now. Which is overall a win as it means testing the persistent
      nodemap more and having less special cases.
      
      In short, having inline changelog is mostly useless and an endless source of
      pain. We get rid of it.
      dcaa2df1f688
  6. Oct 05, 2023
  7. May 02, 2022
  8. Jan 07, 2022
    • Anton Shestakov's avatar
      branchmap: skip obsolete revisions while computing heads · f8f2ecdde4b5
      Anton Shestakov authored
      It's time to make this part of core Mercurial obsolescence-aware.
      
      Not considering obsolete revisions when computing heads is clearly what
      Mercurial should do. But there are a couple of small issues:
      
      - Let's say tip of the repo is obsolete. There are two ways of finding tiprev
        for branchcache (both are in use): looking at input data for update() and
        looking at computed heads after update(). Previously, repo tip would be
        tiprev of the branchcache. With this patch, an obsolete revision can no
        longer be tiprev. And depending on what way we use for finding tiprev (input
        data vs computed heads) we'll get a different result. This is relevant when
        recomputing cache key from cache contents, and may lead to updating cache for
        obsolete revisions multiple times (not from scratch, because it still would
        be considered valid for a subset of revisions in the repo).
      
      - If all commits on a branch are obsolete, the branchcache will include that
        branch, but the list of heads will be empty (that's why there's now `if not
        heads` when recomputing tiprev/tipnode from cache contents). Having an entry
        for every branch is currently required for notify extension (and
        test-notify.t to pass), because notify doesn't handle revsets in its
        subscription config very well and will throw an error if e.g. a branch
        doesn't exist.
      
      - Cloning static HTTP repos may try to stat() a non-existent obsstore file. The
        issue is that we now care about obsolescence during clone, but statichttpvfs
        doesn't implement a stat method, so a regular vfs.stat() is used, and it
        assumes that file is local and calls os.stat().  During a clone, we're trying
        to stat() .hg/store/obsstore, but in static HTTP case we provide a literal
        URL to the obsstore file on the remote as if it were a local file path. On
        windows it actually results in a failure in test-static-http.t.
      
      The first issue is going to be addressed in a series dedicated to making sure
      branchcache is properly and timely written on disk (it wasn't perfect even
      before this patch, but there aren't enough tests to demonstrate that). The
      second issue will be addressed in a future patch for notify extension that will
      make it not raise an exception if a branch doesn't exist. And the third one was
      partially addressed in the previous patch in this series and will be properly
      fixed in a future patch when this series is accepted.
      
      filteredhash() grows a keyword argument to make sure that branchcache is also
      invalidated when there are new obsolete revisions in its repo view. This way
      the on-disk cache format is unchanged and compatible between versions (although
      it will obviously be recomputed when switching versions before/after this patch
      and the repo has obsolete revisions).
      
      There's one test that uses plain `hg up` without arguments while updated to a
      pruned commit. To make this test pass, simply return current working directory
      parent. Later in this series this code will be replaced by what prune command
      does: updating to the closest non-obsolete ancestor.
      
      Test changes:
      
      test-branch-change.t: update branch head and cache update message. The head of
      default listed in hg heads is changed because revision 2 was rewritten as 7,
      and 1 is the closest ancestor on the same branch, so it's the head of default
      now.
      
      The cache invalidation message appears now because of the cache hash change,
      since we're now accounting for obsolete revisions. Here's some context:
      
      "served.hidden" repo filter means everything is visible (no filtered
      revisions), so before this series branch2-served.hidden file would not contain
      any cache hash, only revnum and node. Now it also has a hash when there are
      obsolete changesets in the repo. The command that the message appears for is
      changing branch of 5 and 6, which are now obsolete, so the cache hash changes.
      
      In general, when cache is simply out-of-date, it can be updated using the old
      version as a base. But if cache hash differs, then the cache for that
      particular repo filter is recomputed (at least with the current
      implementation). This is what happens here.
      
      test-obsmarker-template.t: the pull reports 2 heads changed, but after that the
      repo correctly sees only 1. The new message could be better, but it's still an
      improvement over the previous one where hg pull suggested merging with an
      obsolete revision.
      
      test-obsolete.t: we can see these revisions in hg log --hidden, but they
      shouldn't be considered heads even with --hidden.
      
      test-rebase-obsolete{,2}.t: there were new heads created previously after
      making new orphan changesets, but they weren't detected. Now we are properly
      detecting and reporting them.
      
      test-rebase-obsolete4.t: there's only one head now because the other head is
      pruned and was falsely reported before.
      
      test-static-http.t: add obsstore to the list of requested files. This file
      doesn't exist on the remotes, but clients want it anyway (they get 404). This
      is fine, because there are other nonexistent files that clients request, like
      .hg/bookmarks or .hg/cache/tags2-served.
      
      Differential Revision: https://phab.mercurial-scm.org/D12097
      f8f2ecdde4b5
  9. Jan 11, 2022
  10. Nov 20, 2021
  11. Mar 04, 2021
  12. Nov 23, 2020
  13. Oct 22, 2020
  14. May 11, 2020
  15. Feb 09, 2019
  16. Jan 26, 2019
  17. Sep 19, 2018
  18. Sep 04, 2018
  19. May 01, 2018
  20. Apr 04, 2018
  21. Jan 18, 2018
    • Boris Feld's avatar
      revbranchcache: advertise and use 'rbc' exchange capability · 2090044a288d
      Boris Feld authored
      The feature is now advertised and use.
      
      Updating the branchmap cache can be very expensive (up to minutes on large
      repository) and fetching revision branch data is about 80% of that. Exchanging
      the rev branch cache over the wire really help to recover from branch map
      invalidation.
      
      (There is a good chance other in flight chance would conflict on
      test-http-bad-server.t and other. So here is a small note to help update that
      test again: capabilities=19bytes, part-107bytes)
      2090044a288d
  22. Oct 25, 2017
  23. Oct 12, 2017
    • Denis Laxalde's avatar
      transaction-summary: show the range of new revisions upon pull/unbundle (BC) · eb586ed5d8ce
      Denis Laxalde authored
      Upon pull or unbundle, we display a message with the range of new revisions
      fetched. This revision range could readily be used after a pull to look out
      what's new with 'hg log'. The algorithm takes care of filtering "obsolete"
      revisions that might be present in transaction's "changes" but should not be
      displayed to the end user.
      eb586ed5d8ce
  24. Jul 29, 2017
    • Gregory Szorc's avatar
      statichttprepo: implement wlock() (issue5613) · 8b00c723cee1
      Gregory Szorc authored
      statichttprepo inherits from localrepository. In doing so, it
      obtains default implementations of various methods, like wlock().
      
      Before this change, tags cache writing would call repo.wlock().
      This failed on statichttprepo due to localrepository's wlock()
      looking for an instance attribute that doesn't exist on statichttprepo
      (statichttprepo doesn't call localrepository.__init__).
      
      We /could/ define missing attributes until the base wlock() works.
      However, a statichttprepo is remote and read-only and can't be
      locked. The class already has a lock() that short circuits. So
      it makes sense to implement a short-circuited wlock() as well. That
      is what this patch does.
      
      LockError is expected to be raised when locking fails. The constructor
      takes a number of arguments that are local repository centric. Rather
      than rework LockError to not require them (which would not be
      appropriate for stable), this commit populates dummy values. I don't
      believe they'll ever be seen by the user, as lock failures on
      static http repos should be limited to well-defined (and tested)
      scenarios. We can and should revisit the LockError type to improve
      this.
      8b00c723cee1
    • Gregory Szorc's avatar
      test: add tests for branches and tags with static http repo (issue5613) · 075823a6161b
      Gregory Szorc authored
      Mercurial currently fails to clone by revision on static http
      repos with tags. The added tests demonstrate this.
      075823a6161b
  25. Jun 20, 2017
  26. Mar 31, 2017
  27. Mar 30, 2017
    • Pierre-Yves David's avatar
      run-tests: auto-replace 'TXNID' output · 728d37353e1e
      Pierre-Yves David authored
      Hooks related to the transaction are aware of the transaction id. By definition
      this txn-id is unique and different for each transaction. As a result it can
      never be predicted in test and always needs matching. As a result, touching any
      like with this data is annoying. We solve the problem once and for all by
      installing an automatic replacement. In test, this will now show as:
      
        TXNID=TXN:$ID$
      728d37353e1e
  28. Oct 28, 2016
    • Katsunori FUJIWARA's avatar
      tests: invoke printenv.py via sh -c for test portability · 34a5f6c66bc5
      Katsunori FUJIWARA authored
      On Windows platform, invoking printenv.py directly via hook is
      problematic, because:
      
        - unless binding between *.py suffix and python runtime, application
          selector dialog is displayed, and running test is blocked at each
          printenv.py invocations
      
        - it isn't safe to assume binding between *.py suffix and python
          runtime, because application binding is easily broken
      
          For example, installing IDE (VisualStudio with Python Tools, or
          so) often requires binding between source files and IDE itself.
      
      This patch invokes printenv.py via sh -c for test portability. This is
      a kind of follow up for d19787db6fe0, which eliminated explicit
      "python" for printenv.py. There are already other 'sh -c "printenv.py"'
      in *.t files, and this fix should be reasonable.
      
      This changes were confirmed in cases below:
      
        - without any application binding for *.py suffix
        - with binding between *.py suffix and VisualStudio
      
      This patch also replaces "echo + redirection" style with "heredoc"
      style, because:
      
        - hook command line is parsed by cmd.exe as shell at first, and
        - single quotation can't quote arguments on cmd.exe, therefore,
        - "printenv.py foobar" should be quoted by double quotation, but
        - nested quoting (or tricky escaping) isn't readable
      34a5f6c66bc5
  29. Jul 12, 2016
    • Augie Fackler's avatar
      tests: relax "Connection refused" match · 280528245ecf
      Augie Fackler authored
      We already had the match relaxed on Windows, but on Google Compute
      Engine VMs I'm seeing "Network is unreachable" instead of "Connection
      refused". At this point, just give up and make sure we get an error back.
      280528245ecf
  30. Jan 06, 2016
    • Mateusz Kwapich's avatar
      hooks: add HG_NODE_LAST to txnclose and changegroup hook environments · d6d3cf5fda6f
      Mateusz Kwapich authored
      Sometimes a txnclose or changegroup hook wants to iterate through all
      the changesets in transaction: in that situation usually the revset
      `$HG_NODE:` is used to select the revisions. Unfortunately this revset
      sometimes may contain too many changesets because we don't have the
      write lock while the hook runs newer changes may be added to
      repository in the meantime.
      
      That's why there is a need for extra variable carrying the information about
      the last change in the transaction.
      d6d3cf5fda6f
  31. Jun 16, 2015
    • Matt Harbison's avatar
      verify: check the subrepository references in .hgsubstate · f1d46075b13a
      Matt Harbison authored
      While hopefully atypical, there are reasons that a subrepository revision can be
      lost that aren't covered by corruption of the .hgsubstate revlog.  Such things
      can happen when a subrepo is amended, stripped or simply isn't pulled from
      upstream because the parent repo revision wasn't updated yet.  There's no way to
      know if it is an error, but this will find potential problems sooner than when
      some random revision is updated.
      
      Until recently, convert made no attempt at rewriting the .hgsubstate file.  The
      impetuous for this is to verify the conversion of some repositories, and this is
      orders of magnitude faster than a bash script from 0..tip that does an
      'hg update -C $rev'.  But it is equally useful to determine if everything has
      been pulled down before taking a thumb drive on the go.
      
      It feels somewhat wrong to leave this out of verifymod (mostly because the file
      is already read in there, and the final summary is printed before the subrepos
      are checked).  But verifymod looks very low level, so importing subrepo stuff
      there seems more wrong.
      f1d46075b13a
  32. Jun 08, 2015
  33. Apr 15, 2015
Loading