Skip to content
Snippets Groups Projects
  1. Feb 09, 2016
  2. Feb 14, 2016
    • Kostia Balytskyi's avatar
      histedit: break _histedit function into smaller pieces · df206e030c59
      Kostia Balytskyi authored
      We add _getgoal, _validateargs.
      
      This is a part of bigger effort to refactor histedit. Initial steps are to
      break _histedit function into smaller pieces which will supposedly be more
      understandable. After this is done, I will have a better understanding
      of how histedit works and apply that to fix issue4800.
      df206e030c59
    • Kostia Balytskyi's avatar
      histedit: break _histedit function into smaller pieces (add _continueaction) · 8fc55388ece5
      Kostia Balytskyi authored
      This is a part of bigger effort to refactor histedit. Initial steps are to
      break _histedit function into smaller pieces which will supposedly be more
      understandable. After this is done, I will have a better understanding
      of how histedit works and apply that to fix issue4800.
      8fc55388ece5
  3. Feb 01, 2016
  4. Feb 08, 2016
  5. Feb 06, 2016
    • Martin von Zweigbergk's avatar
      match: override 'visitdir' in subdirmatcher · 92f2c69ee5a5
      Martin von Zweigbergk authored
      The manifest.manifest class has a _treeinmem member than one can
      manually set to True to test that the treemanifest class works as a
      drop-in replacement for manifestdict (which is mostly a requirement
      for treemanifest repos to work). However, it doesn't quite work at the
      moment. These tests fail:
      
      test-largefiles-misc.t
      test-rebase-newancestor.t
      test-subrepo.t
      test-subrepo-deep-nested-change.t
      test-subrepo-recursion.t
      
      All but test-rebase-newancestor.t fail because they trigger calls to
      subdirmatcher.visitdir(), which tries to access a _excluderoots field
      that does not exist on the subdirmatcher. Let's fix that by overriding
      visitdir() in a similar way to how matchfn is overridden, i.e. by
      prepending the directory before calling the superclass method.
      92f2c69ee5a5
  6. Jan 09, 2016
  7. Dec 15, 2015
  8. Feb 04, 2016
  9. Feb 14, 2016
    • timeless's avatar
      cmdutil: provide a way to report how to continue · ed4d06f180b8
      timeless authored
      checkafterresolved allows Mercurial to suggest what command to
      use next. If users try to continue the wrong command, there
      wasn't a good way for the command to suggest what to do next.
      
      Split checkmdutil into howtocontinue and checkafterresolved.
      Introduce wrongtooltocontinue which handles raising an Abort with
      the hint from howtocontinue.
      ed4d06f180b8
  10. Feb 13, 2016
    • Katsunori FUJIWARA's avatar
      hg: make cachedlocalrepo cache appropriate repoview object · 91a827e760df
      Katsunori FUJIWARA authored
      Before this patch, 'cachedlocalrepo' always caches "visible" repoview
      object, because 'cachedlocalrepo' uses "visible" repoview returned by
      'hg.repository()' without any additional processing.
      
      If the client of 'cachedlocalrepo' wants "served" repoview, some
      objects to be cached are discarded unintentionally.
      
          1. 'cachedlocalrepo' newly caches "visible" repoview object
             (call it VIEW1)
      
          2. 'cachedlocalrepo' returns VIEW1 to the client of it at 'fetch()'
      
          3. the client gets "served" repoview object by 'filtered("served")'
             on VIEW1 (call this "served" repoview VIEW2)
      
          4. accessing to 'repo.changelog' implies:
             - instantiation of changelog via 'localrepository.changelog'
             - instantiation of "filtered changelog" via 'repoview.changelog'
      
          5. "filtered changelog" above is cached in VIEW2
      
          6. VIEW2 is discarded after processing, because there is no
             reference to it
      
          7. 'cachedlocalrepo' returns VIEW1 cached at (1) above to the
             client at next 'fetch()'
      
          8. 'filtered("served")' on VIEW1 at the client side creates new
             "served" repoview again, because VIEW1 is "visible"
             (call this new "served" repoview VIEW3)
      
          9. accessing to 'repo.changelog' implies instantiation of filtered
             changelog again, because "filtered changelog" is cached in
             VIEW2 at (5), but not in VIEW3 currently used
      
          10. (go to (7) above)
      
      As described above, "served" repoview object and "filtered changelog"
      cached in it are discarded always, even if the repository itself
      hasn't been changed since last access.
      
      For example, in the case of 'hgweb_mod.hgweb', "newly caching" occurs,
      when:
      
        - all cached objects are already assigned to another threads
          (in this case, repoview is created in 'cachedlocalrepo.copy()')
      
        - or, stat of '00changelog.i' is changed from last access
          (in this case, repoview is created in 'cachedlocalrepo.fetch()')
      
          once changes are pushed via HTTP, this always occurs.
      
      The root cause of this inefficiency is that 'cachedlocalrepo' always
      caches "visible" repoview object, even if the client of it wants
      another view.
      
      To make 'cachedlocalrepo' cache appropriate repoview object, this
      patch adds additional filtering on the repo object returned by
      'hg.repository()'. It is assumed that initial repoview object should
      be already filtered by expected view.
      
      After this patch:
      
        - 'filtered("served")' on VIEW1 at (3)/(7) above returns VIEW1
          itself, because VIEW1 is now "served", and
      
        - VIEW2 and VIEW3 equal VIEW1
      
        - therefore, "filtered changelog" is cached in VIEW1, and reused
          intentionally
      91a827e760df
  11. Feb 14, 2016
    • Pierre-Yves David's avatar
      rebase: perform update through the 'update' command · 0e3835c7e1cf
      Pierre-Yves David authored
      The update logic have grow more and more complicated over time (eg bookmark
      movement, new destination logic, warning on other head, etc). The rebase
      extension was reimplementing its own basic version of update to be used by 'hg
      pull --rebase'. We remove the custom code and use a combination of higher level
      functions.
      
      A test is added to check that the update is properly warning about other branch
      heads.
      0e3835c7e1cf
  12. Feb 13, 2016
    • Pierre-Yves David's avatar
      rebase: 'hg pull --rebase' now update only if there was nothing to rebase · 41a0fb2b4bbc
      Pierre-Yves David authored
      I recently discovered that 'hg pull --rebase' was also running an update. And it
      was running it in all cases as long as the update would move the working copy
      somewhere else...
      
      This felt wrong and it actually is. This 'update' call is introduced in
      92455c1d6f83. In that commit the intent is very clear. The update should happen
      only when there was nothing to rebase. The implementation did not check if a
      rebase was performed because, at that time, rebase would always leave you on the
      top most changeset. Being on that top most changeset result in a no-op update
      and the step was skipped.
      
      However 9c78ed396075 changed rebase behavior to preserve the working copy
      parent, so if we are not on a head at pull time, the code performs both a rebase
      and an update.
      
      This changeset introduce a test for this case and restore the intended behavior.
      
      There are other issues with this custom update code but they will be addressed
      in later changeset (eg: own destination logic, lack of heads warning).
      
      I'm not super happy with the explicitly comparison 'rebase(...) == 1' but a
      later series will have a cleaner way to handle it anyway (while making 'rebase'
      pick its default destination like 'merge').
      41a0fb2b4bbc
  13. Feb 08, 2016
    • Durham Goode's avatar
      filectx: replace use of _filerev with _filenode · ba8257cb53e8
      Durham Goode authored
      _filerev depends on the filelog implementation using revlogs and linkrevs.
      Alternative implementations, like remotefilelog, do not have rev numbers, so
      this call fails. Replacing it with _filenode means it doesn't rely on rev
      numbers, and doesn't cost anything extra, since _filerev is using _filenode
      under the hood anyway.
      ba8257cb53e8
  14. Feb 03, 2016
  15. Feb 08, 2016
    • Martin von Zweigbergk's avatar
      verify: use similar language for missing manifest and file revisions · 2a03a365f645
      Martin von Zweigbergk authored
      When a changeset refers to a manifest revision that's not found in the
      manifest log, we say "changeset refers to missing revision X", but
      when a manifest refers to file revision that's not found in the
      filelog, we say "X in manifests not found". The language used for
      missing manifest revisions seems clearer, so let's use that for
      missing filelog revisions too.
      2a03a365f645
  16. Feb 02, 2016
    • Martin von Zweigbergk's avatar
      verify: include "manifest" prefix in a few more places · d2e0d57824c2
      Martin von Zweigbergk authored
      We include the "manifest" prefix on most other errors, so it seems
      consistent to add them to the remaining messages too. Also, having the
      "manifest" prefix will be more consistent with having the directory
      prefix there when we add support for treemanifests. With the
      "manifest" at the beginning, let's remove the now-redundant
      "manifest" in the message itself.
      d2e0d57824c2
    • Martin von Zweigbergk's avatar
      verify: drop unnecessary check for nullid · 334a3aa677fb
      Martin von Zweigbergk authored
      In eb914541a950 (verify: filter messages about missing null manifests
      (issue2900), 2011-07-13), we started ignoring nullid in the list of
      manifest nodeids to check. Then, in b32a30da608d (verify: do not choke
      on valid changelog without manifest, 2012-08-21), we stopped adding
      nullid to the list to start with. So let's drop the left-over check
      now.
      334a3aa677fb
  17. Jan 31, 2016
    • Martin von Zweigbergk's avatar
      verify: move cross-checking of changeset/manifest out of _crosscheckfiles() · 06205989264b
      Martin von Zweigbergk authored
      Reasons:
      
       * _crosscheckfiles(), as the name suggests, is about checking that
         the set of files files mentioned in changesets match the set of
         files mentioned in the manifests.
      
       * The "checking" in _crosscheckfiles() looked rather strange, as it
         just emitted an error for *every* entry in mflinkrevs. The reason
         was that these were the entries remaining after the call to
         _verifymanifest(). Moving all the processing of mflinkrevs into
         _verifymanifest() makes it much clearer that it's the remaining
         entries that are a problem.
      
      Functional change: progress is no longer reported for "crosschecking"
      of missing manifest entries. Since the crosschecking phase takes a
      tiny fraction of the verification, I don't think this is a
      problem. Also, any reports of "changeset refers to unknown manifest"
      will now come before "crosschecking files in changesets and
      manifests".
      06205989264b
  18. Feb 01, 2016
    • Martin von Zweigbergk's avatar
      tests: add tests for missing revlogs and revlog entries · 2b41f8655bbc
      Martin von Zweigbergk authored
      The verify code is pretty poorly tested. It's easy to test missing
      revlogs and missing revlog entries, so let's add tests for that.
      
      Also add some more tests corrupting each type of revlog, so we test
      the messages presented when reading a revision fails. The pure and
      native implementations produce different error messages, so we have to
      use (glob) in the tests.
      2b41f8655bbc
  19. Feb 12, 2016
  20. Feb 08, 2016
    • Pierre-Yves David's avatar
      destutil: document various failure cases · 1fc7b5363871
      Pierre-Yves David authored
      We document what various conditional branch mean and clarify that they are
      exclusive (since they all end up in with exception raised).
      1fc7b5363871
    • Pierre-Yves David's avatar
      destutil: consistently retrieve 'p1' and 'branch' · 96f8baddbd6a
      Pierre-Yves David authored
      We already read p1 from the dirstate so let's read the branch from it too.
      96f8baddbd6a
    • Pierre-Yves David's avatar
      merge: give priority to "not at head" failures for bare 'hg merge' · 7d852bb47b0a
      Pierre-Yves David authored
      We refuse to pick a destination for a bare 'hg merge' if the working copy is not
      at head. This is meant to prevent strange merge from user who forget to update.
      (Moreover, such merge does not reduce actually the number of heads)
      
      However, we were doing that as the last possible failure type. So user were
      recommended to merge with an explicit head (from this bad location) if the
      branch had too many heads.
      
      We now make "not on branch heads" class of failure the first things to check
      and fail on. The one test that change was actually trying to check for these
      failure (and did not). The new test output is correct.
      7d852bb47b0a
  21. Feb 09, 2016
    • Pierre-Yves David's avatar
      destutil: extract all 'mergedest' abort messages into a dictionary · bd74b5e0d2c0
      Pierre-Yves David authored
      We plan to be able to reuse this function for rebase. The error
      message explicitly refers to "merge" in multiple places. So we'll need
      to be able to use different messages. The first step of that is to
      extract all messages in a dedicated dictionary and use them
      indirectly.
      
      As a side effect it clarifies the actual function and opens the way to
      various cleanups and fixes in future changesets.
      bd74b5e0d2c0
  22. Feb 08, 2016
    • Pierre-Yves David's avatar
      tests: add an explicit destination in some rebase tests · 79437fb352ce
      Pierre-Yves David authored
      As we will make 'rebase' behave more like 'merge', it will no longer pick
      'max(branch(.))' as the default destination. We have to hard code the expected
      destination is multiple tests where it matters. After a careful inspection none
      of theses tests really cares about the default destination behavior and just
      omitted one out of laziness.
      79437fb352ce
    • Pierre-Yves David's avatar
      tests: remove third head in some of the 'rebase-parameters' tests · ab382192337a
      Pierre-Yves David authored
      These tests do not care about that extra branch at all. In future changeset we
      will make rebase behave like merge and abort in case of an ambiguous destination
      (eg: multiple other heads) and that extra branch will make the command
      invocation breaks.
      
      We preventively remove this extra branch from the relevant tests in an
      independant changeset to reduce noise and increase confidence in the final
      change.
      ab382192337a
  23. Feb 07, 2016
Loading