Skip to content
Snippets Groups Projects
  1. Mar 19, 2018
  2. Mar 25, 2018
  3. Mar 31, 2018
  4. Mar 28, 2018
  5. Mar 31, 2018
  6. Mar 28, 2018
    • Matt Harbison's avatar
      server: add an error feedback mechanism for when the daemon fails to launch · f09a2eab
      Matt Harbison authored
      There's a recurring problem on Windows where `hg serve -d` will randomly fail to
      spawn a detached process.  The reason for the failure is completely hidden, and
      it takes hours to get a single failure on my laptop.  All this does is redirect
      stdout/stderr of the child to a file until the lock file is freed, and then the
      parent dumps it out if it fails to spawn.
      
      I chose to put the output into the lock file because that is always cleaned up.
      There's no way to report errors after that anyway.  On Windows, killdaemons.py
      is roughly `kill -9`, so this ensures that junk won't pile up.
      
      This may end up being a case of EADDRINUSE.  At least that's what I saw spit out
      a few times (among other odd errors and missing output on Windows).  But I also
      managed to get the same thing on Fedora 26 by running test-hgwebdir.t with
      --loop -j10 for several hours.  Running `netstat` immediately after killing that
      run printed a wall of sockets in the TIME_WAIT state, which were gone a couple
      seconds later.  I couldn't match up ports that failed, because --loop doesn't
      print out the message about the port that was used.  So maybe the fix is to
      rotate the use of HGPORT[12] in the tests.  But, let's collect some more data
      first.
      f09a2eab
  7. Mar 31, 2018
  8. Mar 19, 2018
    • Connor Sheehan's avatar
      templatefuncs: add mailmap template function · 2a2ce93e
      Connor Sheehan authored
      This commit adds a template function to support the .mailmap file
      in Mercurial repositories. The .mailmap file comes from git, and
      can be used to map new emails and names for old commits. The general
      use case is that someone may change their name or author commits
      under different emails and aliases, which would make these
      commits appear as though they came from different persons. The
      file allows you to specify the correct name that should be used
      in place of the author field specified in the commit.
      
      The mailmap file has 4 possible formats used to map old "commit"
      names to new "proper" names:
      
      1. <proper@email.com> <commit@email.com>
      2. Proper Name <commit@email.com>
      3. Proper Name <proper@email.com> <commit@email.com>
      4. Proper Name <proper@email.com> Commit Name <commit@email.com>
      
      Essentially there is a commit email present in each mailmap entry,
      that maps to either an updated name, email, or both. The final
      possible format allows commits authored by a person who used
      both an old name and an old email to map to a new name and email.
      
      To parse the file, we split by spaces and build a name out
      of every element that does not start with "<". Once we find an element
      that does start with "<" we concatenate all the name elements that preceded
      and add that as a parsed name. We then add the email as the first
      parsed email. We repeat the process until the end of the line, or
      a comment is found. We will be left with all parsed names in a list,
      and all parsed emails in a list, with the 0 index being the proper
      values and the 1 index being the commit values (if they were specified
      in the entry).
      
      The commit values are added as the keys to a dict, and with the proper
      fields as the values. The mapname function takes the mapping object and
      the commit author field and attempts to look for a corresponding entry.
      To do so we try (commit name, commit email) first, and if no results are
      returned then (None, commit email) is also looked up. This is due to
      format 4 from above, where someone may have a mailmap entry with both
      name and email, and if they don't it is possible they have an entry that
      uses only the commit email.
      
      Differential Revision: https://phab.mercurial-scm.org/D2904
      2a2ce93e
  9. Mar 30, 2018
  10. Mar 27, 2018
  11. Mar 30, 2018
  12. Mar 21, 2018
  13. Mar 30, 2018
  14. Mar 27, 2018
  15. Feb 09, 2018
  16. Feb 08, 2018
  17. Feb 03, 2018
  18. Feb 09, 2018
    • Pulkit Goyal's avatar
      infinitepush: move the extension to core from fb-hgext · 03ff17a4
      Pulkit Goyal authored
      This patch moves the infinitepush extension from fb-hgext to core. The
      extension is used to store incoming bundles during a push in bundlestore rather
      than applying them to the revlog.
      
      The extension was copied from the repository revision at
      f27f094e91553d3cae5167c0b1c42ae940f888d5 and following changes were made:
      
        * added `from __future__ import absolute_import` where missing
        * fixed module imports to follow the core style
        * minor fixes for test-check-code.t
        * registered the configs
        * adding the testedwith value to match core's convention
        * removed double newlines to make test-check-commit.t happy
        * added one line doc about extension and marked it as experimental
      
      Only one test file test-infinitepush-bundlestore.t is moved to core and
      following changes are made to file:
      
        * remove dependency of library.sh
        * split the tests into two tests i.e. test-infinitepush.t and
          test-infinitepush-bundlestore.t
        * removed testing related to other facebook's extensions pushrebase, inhibit,
          fbamend
      
      library-infinitepush.sh is also copied from fb-hgext from the same revision and
      following changes are made:
      
        * change the path to infinitepush extension as it's in core with this patch
        * removed sql handling from the file as we are not testing that initially
      
      Currently at this revision, test-check-module-imports.t does not pass as there
      is import of a module from fb/hgext in one the of the file which will be removed
      in the next patch.
      
      This extension right now has a lot of things which we don't require in core like
      `--to`, `--create` flags to `hg bookmark`, logic related to remotenames
      extension and another facebook's extensions, custom bundle2parts which can be
      prevented by using bookmarks bundle part and also logic related to sql store
      which is probably we don't want initially.
      
      The next patches in this series will remove all the unwanted and unrequired
      things from the extension and will make this a nice one.
      
      The end goal is to have a very lighweight extension with no or very less
      wrapping on the client side.
      
      Differential Revision: https://phab.mercurial-scm.org/D2096
      03ff17a4
  19. Mar 30, 2018
  20. Mar 03, 2018
  21. Mar 30, 2018
Loading