Skip to content
Snippets Groups Projects
  1. Dec 22, 2014
    • durin42's avatar
      demandimport: blacklist distutils.msvc9compiler (issue4475) · 2205d00b6d2b
      durin42 authored
      This module depends on _winreg, which is windows-only. Recent versions
      of setuptools load distutils.msvc9compiler and expect it to
      ImportError immediately when on non-Windows platforms, so we need to
      let them do that. This breaks in an especially mystifying way, because
      setuptools uses vars() on the imported module. We then throw an
      exception, which vars doesn't pick up on well. For example:
      
      In [3]: class wat(object):
         ...:     @property
         ...:     def __dict__(self):
         ...:         assert False
         ...:
      
      In [4]: vars(wat())
      ---------------------------------------------------------------------------
      TypeError                                 Traceback (most recent call last)
      <ipython-input-4-2781ada5ffe6> in <module>()
      ----> 1 vars(wat())
      
      TypeError: vars() argument must have __dict__ attribute
      
      Which is similar to the problem we run into.
      2205d00b6d2b
  2. Dec 21, 2014
    • Matt Harbison's avatar
      largefiles: fix a spurious missing file warning with forget (issue4053) · 70afc58c32d3
      Matt Harbison authored
      If an uncommitted and deleted file was forgotten, a warning would be emitted,
      even though the operation was successful.  See the previous patch for
      'remove -A' for the exact circumstances, and details about the cause.
      70afc58c32d3
    • Matt Harbison's avatar
      largefiles: fix a spurious missing file warning with 'remove -A' (issue4053) · 9dd5dfeaab4c
      Matt Harbison authored
      The bug report doesn't mention largefiles, but the given recipe doesn't fail
      unless the largefiles extension is loaded.  The problem only affected normal
      files, whether or not any largefiles are committed, and only files that have
      not been committed yet.  (Files with an 'a' state are dropped from dirstate,
      not marked removed.)  Further, if the named normal file never existed, the
      warning would be printed out twice.
      
      The problem is that the core implementation of remove() calls repo.status(),
      which eventually triggers a dirstate.walk().  When the file isn't seen in the
      filesystem during the walk, the exception handling finds the file in
      dirstate, so it doesn't complain.  However, the largefiles implementation
      called status() again with all of the original files (including the normal
      ones, just dropped).  This time, the exception handler doesn't find the file
      in dirstate and does complain.  This simply excludes the normal files from
      the second repo.status() call, which the largefiles extension has no interest
      is processing anyway.
      9dd5dfeaab4c
    • Matt Harbison's avatar
      largefiles: introduce the 'composelargefilematcher()' method · f1e6b86da4c0
      Matt Harbison authored
      This is a copy/paste (with the necessary tweaks) of the composenormalfilematcher
      method currently on default, which does the inverse- this trims the normal files
      out of the matcher.  It will be used in the next patch.
      f1e6b86da4c0
  3. Dec 18, 2014
  4. Dec 16, 2014
  5. Dec 11, 2014
  6. Dec 12, 2014
    • Augie Fackler's avatar
      manifest: disallow setting the node id of an entry to None · 6f53629ad273
      Augie Fackler authored
      manifest.diff() uses None as a special value to denote the absence of
      a file, so setting a file node to None means you then can't trust
      manifest.diff().
      
      This should also make future manifest work slightly easier.
      6f53629ad273
    • Augie Fackler's avatar
      context: stop setting None for modified or added nodes · b1179dabc6de
      Augie Fackler authored
      Instead use a magic value, so that we can identify modified or added
      nodes correctly when using manifest.diff().
      
      Thanks to Martin von Zweigbergk for catching that we have to update
      _buildstatus as well. That part eluded my debugging for some time.
      b1179dabc6de
  7. Dec 13, 2014
  8. Dec 08, 2014
    • Durham Goode's avatar
      log: fix log revset instability · 424d669118d3
      Durham Goode authored
      The log/graphlog revset was not producing stable results since it was
      iterating over a dict. Now we sort before iterating to guarantee a fixed order.
      
      This fixes some potential flakiness in the tests.
      424d669118d3
  9. Dec 05, 2014
    • Durham Goode's avatar
      log: fix log -f slow path to actually follow history · 9601229ed361
      Durham Goode authored
      The revset created when -f was used with a slow path (for patterns and
      directories) did not actually contain any logic to enforce follow. Instead it
      was depending on the passed in subset to already be limited (which was limited
      to :. but not ::.). This fixes it by adding a '& ::.' to any -f log revset.
      
      hg log -f <file> is still broken, in that it can return results that aren't
      actually ancestors of the current file, but fixing that has major perf
      implications, so we'll deal with it later.
      9601229ed361
  10. Nov 17, 2014
    • Martin von Zweigbergk's avatar
      update: don't overwrite untracked ignored files on update · 30b602168c3b
      Martin von Zweigbergk authored
      When looking for untracked files that would conflict with a tracked
      file in the target revision (or the remote side of a merge), we
      explcitly exclude ignored files. The code was added in 7e30f5f2285f
      (merge: refactor unknown file conflict checking, 2012-02-09), but it
      seems like only unknown, not ignored, files were considered since the
      beginning of time.
      
      Although ignored files are mostly build outputs and backup files, we
      should still not overwrite them. Fix by simply removing the explicit
      check.
      30b602168c3b
  11. Dec 03, 2014
    • Martin von Zweigbergk's avatar
      update: add tests for untracked local file · 689540e6007e
      Martin von Zweigbergk authored
      We don't seem to have any tests for updating to another revision when
      there are untracked files on the local side that conflict with the
      those on the remote side, so let's add tests. This shows how we
      overwrite untracked ignored files when updating to a revision that
      tracks the file.
      689540e6007e
  12. Dec 02, 2014
  13. Dec 01, 2014
  14. Nov 29, 2014
  15. Dec 02, 2014
  16. Dec 01, 2014
  17. Nov 30, 2014
  18. Dec 01, 2014
  19. Nov 28, 2014
    • Mads Kiilerich's avatar
      mq: fix update of headers that occur in the "wrong" order · 94092019e839
      Mads Kiilerich authored
      Mq tried to insert headers in the right order. Sometimes it would stop
      searching before checking all headers and it could thus duplicate a header
      instead of replacing it.
      94092019e839
    • Gregory Szorc's avatar
      hgweb: send proper HTTP response after uncaught exception · dc4d2cd3aa3e
      Gregory Szorc authored
      This patch fixes a bug where hgweb would send an incomplete HTTP
      response.
      
      If an uncaught exception is raised when hgweb is processing a request,
      hgweb attempts to send a generic error response and log that exception.
      
      The server defaults to chunked transfer coding. If an uncaught exception
      occurred, it was sending the error response string / chunk properly.
      However, RFC 7230 Section 4.1 mandates a 0 size last chunk be sent to
      indicate end of the entity body. hgweb was failing to send this last
      chunk. As a result, properly written HTTP clients would assume more data
      was coming and they would likely time out waiting for another chunk to
      arrive.
      
      Mercurial's own test harness was paving over the improper HTTP behavior
      by not attempting to read the response body if the status code was 500.
      This incorrect workaround was added in ba6577a19656 and has been removed
      with this patch.
      dc4d2cd3aa3e
  20. Nov 26, 2014
  21. Nov 25, 2014
    • Pierre-Yves David's avatar
      rename: properly report removed and added file as modified (issue4458) · 2963d5c9d90b
      Pierre-Yves David authored
      The result of 'hg rm' + 'hg rename' disagreed with the one from
      'hg rename --force'. We align them on 'hg move --force' because it agrees with
      what 'hg status' says after the commit.
      
      Stopping reporting a modified file as added puts an end to the hg revert confusion in this
      situation (issue4458).
      
      However, reporting the file as modified also prevents revert from restoring the copy
      source. We fix this in a later changeset.
      
      Git diff also stop reporting the add in the middle of the chain as add. Not
      sure how important (and even wrong) it is.
      2963d5c9d90b
  22. Nov 26, 2014
    • Pierre-Yves David's avatar
      manifest: fix a bug where working copy file 'add' mark was buggy · fd1bab28a8cc
      Pierre-Yves David authored
      Because the same dictionary was used to (1) get node from parent and (2) store
      annotated version, we could end up with buggy values. For example with a chain
      of renames:
      
        $ hg mv b c
        $ hg mv a b
      
      The value from 'b' would be updated as "<old-a>a", then the value of c would be
      updated as "<old-b>a'. With the current dictionary sharing this ends up with:
      
          '<new-c>' == '<old-a>aa'
      
      This value is double-wrong as we should use '<old-b>' and a single 'a'.
      
      We now use a read-only value for lookup. The 'test-rename.t' test is impacted
      because such a chained added file is suddenly detected as such.
      fd1bab28a8cc
    • anatoly techtonik's avatar
      3bd577a3283e
  23. Nov 25, 2014
  24. Nov 21, 2014
    • Durham Goode's avatar
      changegroup: fix file linkrevs during reorders (issue4462) · cc0ff93d0c0c
      Durham Goode authored
      Previously, if reorder was true during the creation of a changegroup bundle,
      it was possible that the manifest and filelogs would be reordered such that the
      resulting bundle filelog had a linkrev that pointed to a commit that was not
      the earliest instance of the filelog revision. For example:
      
      With commits:
      
      0<-1<---3<-4
        \       /
         --2<---
      
      if 2 and 3 added the same version of a file, if the manifests of 2 and 3 have
      their order reversed, but the changelog did not, it could produce a filelog with
      linkrevs 0<-3 instead of 0<-2, which meant if commit 3 was stripped, it would
      delete that file data from the repository and commit 2 would be corrupt (as
      would any future pulls that tried to build upon that version of the file).
      
      The fix is to make the linkrev fixup smarter. Previously it considered the first
      manifest that added a file to be the first commit that added that file, which is
      not true. Now, for every file revision we add to the bundle we make sure we
      attach it to the earliest applicable linkrev.
      cc0ff93d0c0c
Loading