Skip to content
Snippets Groups Projects
  1. Aug 29, 2018
    • Boris Feld's avatar
      phase: report number of non-public changeset alongside the new range · 89630d0b3e23
      Boris Feld authored
      When interacting with non-publishing repository or bundle, it is useful to
      have some information about the phase of the changeset we just pulled.
      
      This changeset updates the "new changesets MIN:MAX" output to also includes
      phases information for non-public changesets. Displaying extra data about
      non-public changesets means the output for exchange with publishing repository
      (the default) is unaffected.
      89630d0b3e23
  2. Jul 05, 2018
  3. May 08, 2018
  4. Apr 04, 2018
    • Gregory Szorc's avatar
      tests: conditionalize tests for various repo features · 7542e97c7867
      Gregory Szorc authored
      Working my down the long tail of test failures due to the simple
      store.
      
      We're now down to 38 failures with the simple store.
      
      Differential Revision: https://phab.mercurial-scm.org/D3096
      7542e97c7867
    • Gregory Szorc's avatar
      simplestore: use a custom store for the simple store repo · c2c8962a9465
      Gregory Szorc authored
      Before, we used the default store, which was based on fncache
      and dotencode. After attempting to port tests to work with the
      simple store, I realized that fncache was more trouble than it is
      worth.
      
      This commit implements a proper store type for the simple repo -
      one that isn't based off fncache.
      
      This causes a number of new test failures because of tests
      expecting the full fncache store filename encoding. I may
      extend the store format in a subsequent commit to take the
      filename encoding parts of fncache that we can take
      (basically everything except hash encoding, since that isn't
      reversible). But for now, let's use encoded store.
      
      As part of this, we implement proper requirements support for
      repos created with the simple store. This should have been
      done from the beginning, as a requirement is needed to lock
      out clients that don't understand a storage format.
      
      A new hghave feature advertising the presence of fncache in repos
      has been added. Most tests touching the fncache are now conditional
      on that feature.
      
      Other tests have added the optional repo requirement to output.
      
      Differential Revision: https://phab.mercurial-scm.org/D3095
      c2c8962a9465
    • Gregory Szorc's avatar
      tests: conditionalize tests based on presence of revlogs for files · cbc4425e81b5
      Gregory Szorc authored
      ~85 tests don't like our non-revlog file store for various reasons.
      
      This commit introduces hghave functionality for declaring and querying
      repository features. By default, we assume repositories have
      revlog-based file storage. But if the HGREPOFEATURES environment
      variable is set, we can override the default set of repository
      features. If you run the test harness with our simplestorerepo
      extension and an environment variable set to the proper value, you
      can override the hghave defaults to agree with simplestorerepo's
      version of reality.
      
      Various tests have been modified so behavior dependent on revlog-based
      file storage is marked as such.
      
      This fixes a handful of test failures with our custom file storage
      extension. But dozens remain. The point of this commit is to demonstrate
      how tests will need to be modified to account for custom storage
      implementations.
      
      TBH, I'm not convinced hghave is the proper layer for repository
      feature detection. I /think/ we'll eventually want something in
      run-tests.py itself. But that would require inventing a new primitive
      in the test harness. This is all very alpha at the moment. So I think
      hghave is an acceptable place to hang this feature detection. I think
      the right time to be thinking about integrating this into run-tests.py
      is *after* we have a stable alternate storage implementation in core.
      For now, let's try to make progress towards the idea of an alternate
      storage backend.
      
      Differential Revision: https://phab.mercurial-scm.org/D3030
      cbc4425e81b5
  5. Apr 03, 2018
    • Gregory Szorc's avatar
      tests: use `hg unbundle` instead of `hg pull` in some tests · 5d10f41ddcc4
      Gregory Szorc authored
      `hg pull <bundle>` uses the special "bundlerepo" repository. The
      bundlerepo code makes many assumptions about the storage of
      repositories. It will be difficult to teach bundlerepo to use
      non-revlog storage before a better storage interface is established.
      
      Many test failures using our "simple store" are related to
      bundlerepo: the simple store just isn't compatible with bundlerepo
      because of storage assumptions in bundlerepo.
      
      In order to mitigate the impact of bundlerepo on our code base,
      this commit changes various tests to use `hg unbundle` instead
      of `hg pull`. This bypasses the bundlerepo code.
      
      Tests exercising exchange functionality have not been altered, as
      they should be using `hg pull` and going through the bundlerepo
      code paths.
      
      Differential Revision: https://phab.mercurial-scm.org/D3059
      5d10f41ddcc4
  6. Apr 04, 2018
  7. Feb 21, 2018
    • Boris Feld's avatar
      bundle: include advisory rev branch cache part in bundle2 bundle · b89a7ef29013
      Boris Feld authored
      `hg bundle` command producing bundle2 will now include an optional part
      containing the revision-branch cache data.
      
      The data sent are mostly nodes so it is quite compact.  The goal of the
      rev-branch-cache is to speed up branch map computation, especially when the
      branchmap gets invalidated so we send data for all exchanged changesets. In
      addition, computing the relevant heads to send in case of partial pulling would
      be challenging.
      
      As a reminder, the rev branch cache data significantly speed up branch
      computation. Having it around provides a small speedup to pull/clone and much
      higher tolerance to branch map cache invalidation that might happens from later
      commands.
      
      On the Mercurial repository, computing the visible branchmap from scratch move
      from 2.00 seconds to 0.34s (a -83% speedup).
      
      Using this new part, Unbundling the full Mercurial repository moves from 25.736
      seconds to 24.030 seconds (around -7% speedup). The bundle size increase is
      around 3% (from 22.43 MB to 23.13MB)
      
      
      On an half a million revision repository with twenty thousand
      branches, computing the branchmap moves from 75 seconds to 45 second (-40%) if
      the caches is used.
      
      A bundle containing 50 000 changesets in such repository get a 0.5% size
      increase from such part for a -3% unbundling time speedup.
      b89a7ef29013
  8. Jan 18, 2018
  9. Jan 15, 2018
    • Martin von Zweigbergk's avatar
      evolution: report new unstable changesets · 1a09dad8b85a
      Martin von Zweigbergk authored
      This adds a transaction summary callback that reports the number of
      new orphan, content-divergent and phase-divergent changesets.
      
      The code for reporting it is based on the code from the evolve
      extension, but simplified a bit. It simply counts the numbers for each
      kind of instability before and after the transaction. That's obviously
      not very efficient, but it's easy to reason about, so I'm doing this
      as a first step that can make us quite confident about the test case
      changes. We can optimize it later and make sure that the tests are not
      affected. The code has been used in the evolve extension for a long
      time and has apparently been sufficiently fast, so it doesn't seem
      like a pressing issue.
      
      Unlike the evolve extension's version of this report, this version
      applies to all commands (or all transactions run as part of any
      command, to be exact).
      
      Differential Revision: https://phab.mercurial-scm.org/D1867
      1a09dad8b85a
  10. Dec 22, 2017
  11. Dec 11, 2017
    • Matt Harbison's avatar
      tests: remove (glob) annotations that were only for '\' matches · 4441705b7111
      Matt Harbison authored
      # skip-blame because this was mechanically rewritten the following script.  I
      ran it on both *.t and *.py, but none of the *.py changes were proper.  All *.t
      ones appear to be, and they run without addition failures on both Windows and
      Linux.
      
        import argparse
        import os
        import re
      
        ap = argparse.ArgumentParser()
        ap.add_argument('path', nargs='+')
        opts = ap.parse_args()
      
        globre = re.compile(r'^(.*) \(glob\)(.*)$')
      
        for p in opts.path:
            tmp = p + '.tmp'
            with open(p, 'rb') as src, open(tmp, 'wb') as dst:
                for line in src:
                    m = globre.match(line)
                    if not m or '$LOCALIP' in line or '*' in line:
                        dst.write(line)
                        continue
                    if '?' in line[:-3] or ('?' in line[:-3] and line[-3:] != '(?)'):
                        dst.write(line)
                        continue
                    dst.write(m.group(1) + m.group(2) + '\n')
            os.unlink(p)
            os.rename(tmp, p)
      4441705b7111
  12. Nov 01, 2017
  13. Oct 17, 2017
  14. 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
  15. Oct 05, 2017
  16. Oct 03, 2017
    • Saurabh Singh's avatar
      test-strip: make test compatible with chg · 40b6d25ed2d5
      Saurabh Singh authored
      The test was using reposetup which had the logic for stripping
      commits. This leads to a situation where if the reposetup was called twice for
      an extension (which can happen with chg running), the stripped node would not
      be found the second time. Therefore, this commit changes the test to put the
      stripping logic inside commands instead of the reposetup. This ensures that the
      stripping logic is invoked only when the command is invoked and thus, avoids
      any problems.
      
      Test Plan:
      Ran the test 'test-strip.t' with and without the '--chg' option.
      
      Differential Revision: https://phab.mercurial-scm.org/D928
      40b6d25ed2d5
  17. Sep 15, 2017
    • Martin von Zweigbergk's avatar
      obsmarker: track operation by default · ecc96506c49d
      Martin von Zweigbergk authored
      We added support for including the operation responsible for creating
      the obsmarker in 3546a771e376 (obsolete: add operation metadata to
      rebase/amend/histedit obsmarkers, 2017-05-09). However, soon
      thereafter, in f432897a9f49 (obsmarker: add an experimental flag
      controlling "operation" recording, 2017-05-20), it was hidden behind a
      config that was off by default. It seems unlikely that people will
      manually turn it on, and obsmarkers/evolution as a whole is still
      experimental anyway, so let's turn on the tracking by default.
      
      Differential Revision: https://phab.mercurial-scm.org/D722
      ecc96506c49d
  18. Sep 18, 2017
  19. Sep 14, 2017
    • Martin von Zweigbergk's avatar
      repair: preserve phase also when not using generaldelta (issue5678) · 91f0677dc920
      Martin von Zweigbergk authored
      It seems like we used to pick the oldest possible version of the
      changegroup to use for bundles created by the repair module (used
      e.g. by "hg strip" and for temporary bundles by "hg rebase"). I tried
      to preserve that behavior when I created the changegroup.safeversion()
      method in 3b2ac2115464 (changegroup: introduce safeversion(),
      2016-01-19).
      
      However, we have recently chagned our minds and decided that these
      commands are only used locally and downgrades are unlikely. That
      decicion allowed us to start adding obsmarker and phase information to
      these bundles. However, as the bug report shows, it means we get
      different behavior e.g. when generaldelta is not enabled (because when
      it was enabled, it forced us to use bundle2). The commit that actually
      caused the reported bug was 8e3021fd1a44 (strip: include phases in
      bundle (BC), 2017-06-15).
      
      So, since we now depend on having more information in the bundles,
      let's make sure we instead pick the newest possible changegroup
      version.
      
      Differential Revision: https://phab.mercurial-scm.org/D715
      91f0677dc920
    • Martin von Zweigbergk's avatar
      tests: add test for issue5678 · b5d7e7d5c573
      Martin von Zweigbergk authored
      In addition to a test case for the direct problem described in the bug
      report, this also adds a test case showing how obsmarkers can also get
      lost when not using generaldelta.
      
      Differential Revision: https://phab.mercurial-scm.org/D714
      b5d7e7d5c573
  20. Aug 23, 2017
  21. Aug 22, 2017
  22. Aug 04, 2017
  23. Jul 15, 2017
    • Martin von Zweigbergk's avatar
      drawdag: include files from both parents in merge commits · 0103e7187237
      Martin von Zweigbergk authored
      Consider a graph like this:
      
        D
        |\
        B C
        |/
        A
      
      drawdag will add a file called A in commit A, file B in B, file C in
      C. That's fine and expected. In merge commits like D, I would expect
      the files and their contents to be taken from the parent commits, so
      commit D in this example would have files A, B, and C. However,
      drawdag will instead add the file D compared to the first
      parent. Depending on whether B or C got a smaller nodeid, the contents
      of D would be {A, B, D} or {A, C, D}. This patch changes it to to be
      {A, B, C}.
      
      Differential Revision: https://phab.mercurial-scm.org/D92
      0103e7187237
  24. Jul 16, 2017
  25. Jun 26, 2017
    • Jun Wu's avatar
      scmutil: make cleanupnodes delete divergent bookmarks · 4bae3c117b57
      Jun Wu authored
      cleanupnodes takes care of bookmark movement, and bookmark movement could
      cause bookmark divergent resolution as a side effect. This patch adds such
      bookmark divergent resolution logic so future rebase migration will be
      easier.
      
      The revset is carefully written to be equivalent to what rebase does today.
      Although I think it might make sense to remove divergent bookmarks more
      aggressively, for example:
      
          F   book@1
          |
          E   book@2
          |
          | D book
          | |
          | C
          |/
          B   book@3
          |
          A
      
      When rebase -s C -d E, "book@1" will be removed, "book@3" will be kept,
      and the end result is:
      
          D   book
          |
          C
          |
          F
          |
          E   book@2 (?)
          |
          B   book@3
          |
          A
      
      The question is should we keep book@2? The current logic keeps it. If we
      choose not to (makes some sense to me), the "deleterevs" revset could be
      simplified to "newnode % oldnode".
      
      For now, I just make it compatible with the existing behavior. If we want to
      make the "deleterevs" revset simpler, we can always do it in the future.
      4bae3c117b57
  26. Jun 25, 2017
    • Jun Wu's avatar
      scmutil: add a cleanupnodes method for developers · 65cadeea6c22
      Jun Wu authored
      It's now common that an old node gets replaced by zero or more new nodes,
      that could happen with amend, rebase, histedit, etc. And it's a common
      requirement to do bookmark movements, strip or obsolete nodes and even
      moving working copy parent.
      
      Previously, amend, rebase, history have their own logic doing the above.
      This patch is an attempt to unify them and future code.
      
      This enables new developers to be able to do "replace X with Y" thing
      correctly, without any knowledge about bookmarks, strip or obsstore.
      
      The next step will be migrating rebase to the new API, so it works inside a
      transaction, and its code could be simplified.
      65cadeea6c22
    • Jun Wu's avatar
      strip: add a delayedstrip method that works in a transaction · fcd1c483f5ea
      Jun Wu authored
      For long, the fact that strip does not work inside a transaction and some
      code has to work with both obsstore and fallback to strip lead to duplicated
      code like:
      
            with repo.transaction():
                ....
                if obsstore:
                    obsstore.createmarkers(...)
            if not obsstore:
                repair.strip(...)
      
      Things get more complex when you want to call something which may call strip
      under the hood. Like you cannot simply write:
      
            with repo.transaction():
                ....
                rebasemod.rebase(...) # may call "strip", so this doesn't work
      
      But you do want rebase to run inside a same transaction if possible, so the
      code may look like:
      
            with repo.transaction():
                ....
                if obsstore:
                    rebasemod.rebase(...)
                    obsstore.createmarkers(...)
            if not obsstore:
                rebasemod.rebase(...)
                repair.strip(...)
      
      That's ugly and error-prone. Ideally it's possible to just write:
      
            with repo.transaction():
                rebasemod.rebase(...)
                saferemovenodes(...)
      
      This patch is the first step towards that. It adds a "delayedstrip" method
      to repair.py which maintains a postclose callback in the transaction object.
      fcd1c483f5ea
  27. Jun 15, 2017
    • Martin von Zweigbergk's avatar
      strip: include phases in bundle (BC) · 8e3021fd1a44
      Martin von Zweigbergk authored
      Before this patch, unbundling a stripped changeset would make it a
      draft (unless the parent was secret). This meant that one would lose
      phase information when stripping and unbundling secret changesets. The
      same thing was true for public changesets. While stripping public
      changesets is generally rare, it's done frequently by e.g. the
      narrowhg extension.
      
      We also include the phases in the temporary bundle, just in case
      stripping were to fail after that point, so the user can still restore
      the repo including phase information. Before this patch, the phases
      were left untouched during the bundling and unbundling of the
      temporary bundle. Only at the end of the transaction would
      phasecache.filterunknown() be called to remove phase roots that were
      no longer valid. We now need to call that also after the first
      stripping, i.e. before applying the temporary bundle. Otherwise
      unbundling the temporary bundle will cause a read of the phase cache
      which has stripped changesets in the cache and that fails.
      
      Like with obsmarkers, we unconditionally include the phases in the
      bundle when stripping (when using bundle2, such as when generaldelta
      is enabled). The reason for doing that for strip but not for bundle is
      that strip bundles are not meant to be shared outside the repo, so we
      don't care as much about compatibility.
      8e3021fd1a44
  28. Jun 06, 2017
  29. May 02, 2017
    • Pierre-Yves David's avatar
      caches: move the 'updating the branch cache' message in 'updatecaches' · c2380b448265
      Pierre-Yves David authored
      We are about to remove the branchmap cache update in changegroup application.
      There is a debug message alongside this update that we do not want to loose. We
      move the message beforehand to simplify the test update in the next changeset.
      The message move is quite noisy and isolating that noise is useful.
      
      Most tests update are just line reordering since the message is issued at a
      later point during the transaction.
      
      After this changes, the message is displayed in more case since local commit
      creation also issue it.
      c2380b448265
  30. Oct 09, 2016
    • Pierre-Yves David's avatar
      help: backout f3c4edfd35e1 (mark boolean flags with [no-] in help) for now · d65e246100ed
      Pierre-Yves David authored
      The ability to negate any boolean flags itself is great, but I think we are not
      ready to expose the help side of it yet.
      
      First, while there exist a handful of such flags whose default value can be
      changed (eg: git diff, patchwork confirmation), there is only a few of them. The
      users who benefit the most from this change are alias users and large
      installation that can deploy extension to change behavior (eg: facebook
      tweakdefault).  So the majority of user who will be affected by a large change
      to command help that is not yet relevant to them. (I expect this to become
      relevant when ui.progressive start to exists).
      
      Below is an example of the impact of the new help on 'hg help diff':
      
        -r --rev REV [+]              revision
        -c --change REV               change made by revision
        -a --[no-]text                treat all files as text
        -g --[no-]git                 use git extended diff format
           --[no-]nodates             omit dates from diff headers
           --[no-]noprefix            omit a/ and b/ prefixes from filenames
        -p --[no-]show-function       show which function each change is in
           --[no-]reverse             produce a diff that undoes the changes
        -w --[no-]ignore-all-space    ignore white space when comparing lines
        -b --[no-]ignore-space-change ignore changes in the amount of white space
        -B --[no-]ignore-blank-lines  ignore changes whose lines are all blank
        -U --unified NUM              number of lines of context to show
           --[no-]stat                output diffstat-style summary of changes
           --root DIR                 produce diffs relative to subdirectory
        -I --include PATTERN [+]      include names matching the given patterns
        -X --exclude PATTERN [+]      exclude names matching the given patterns
        -S --[no-]subrepos            recurse into subrepositories
      
      Another issue with the current state of help, the default value for the
      flag is not conveyed to the user. For example in the 'backout' help, there is
      no real distinction between "--[no-]backup" (default to True) and "--[no-]keep"
      (default) to False:
      
        --[no-]backup        no backups
        --[no-]keep          do not modify working directory during strip
      
      In addition, I've discussed with Augie Fackler and the last batch of the work on
      this have burned him out quite some. Therefore he is not intending to perform
      any more work on this topic. Quoting him, he would rather see the help part
      backed out than spending more time on it.
      
      I do not think we are ready to expose this to users in 4.0 (freeze in a week),
      especially because we cannot expect quick improvement on these aspect as this
      topic no longer have an owner. We should be able to reintroduce that change in
      the future when someone get back on it and the main issues are solves:
      
      * Introduction of  ui.progressive makes it relevant for a majority of user,
      * Current default value are efficiently conveyed to the user.
      
      (In addition, the excerpt from diff help show that we still have some issue with
      some negative option like '--nodates' so further improvement are probably
      welcome there.)
      d65e246100ed
  31. Sep 14, 2016
    • Augie Fackler's avatar
      help: mark boolean flags with [no-] to explain that they can be negated · f3c4edfd35e1
      Augie Fackler authored
      That is, help gets tweaked thus:
      
        global options ([+] can be repeated):
         -v --[no-]verbose      enable additional output
      
      
      Other proposals have included:
      
        global options ([+] can be repeated, options marked [?] are boolean flags):
         -v --verbose[?]        enable additional output
      
      and
      
        global options ([+] can be repeated, options marked [^] are boolean flags):
         -v --verbose[^]        enable additional output
      
      which avoid the unfortunate visual noise in this patch. In this
      version's favor, it's consistent with what I'm used to seeing in man
      pages and similar documentation venues.
      f3c4edfd35e1
  32. Sep 20, 2016
  33. Sep 19, 2016
    • Martin von Zweigbergk's avatar
      strip: don't use "full" and "partial" to describe bundles · 769aee32fae0
      Martin von Zweigbergk authored
      The partial bundle is not a subset of the full bundle, and the full
      bundle is not full in any way that i see. The most obvious
      interpretation of "full" I can think of is that it has all commits
      back to the null revision, but that is not what the "full" bundle
      is. The "full" bundle is simply a backup of what the user asked us to
      strip (unless --no-backup). The "partial" bundle contains the
      revisions we temporarily stripped because they had higher revision
      numbers that some commit that the user asked us to strip.
      
      The "full" bundle is already called "backup" in the code, so let's use
      that in user-facing messages too. Let's call the "partial" bundle
      "temporary" in the code.
      769aee32fae0
Loading