Skip to content
Snippets Groups Projects
  1. Nov 07, 2015
  2. Oct 20, 2015
  3. Nov 08, 2015
    • Durham Goode's avatar
      phase: improve retractboundary perf · e3611881
      Durham Goode authored
      The existing retractboundary implementation computed the new boundary by walking
      all descendants of all existing roots and computing the new roots. This is
      O(commits since first root), which on long repos can be hundreds of thousands of
      commits.
      
      The new algorithm only updates roots that are greater than the new root
      locations. For common operations like commit on a repo with the earliest root
      several hundred thousand commits ago, this makes retractboundary go from
      1 second to 0.008 seconds.
      
      I tested it by running the test suite with both implementations and checking
      that the root results were always the identical.
      
      There was some discussion on IRC about the safety of this (i.e. what if the new
      nodes are already part of the phase, etc).  I've looked into it and believe this
      patch is safe:
      
      1) The old existing code already filters the input nodes to only contain nodes
         that require retracting (i.e. we only make node X a new root if the old phase
         is less than the target phase), so there's no chance of us adding a
         unnecessary root to the phase (unless the input root is made unnecessary by
         another root in the same input, but see point #3).
      
      2) Another way of thinking about this is:  the only way the new algorithm would
         be different from the old algorithm is if it added a root that is a
         descendant of an old root (since the old algorithm would've caught this in
         the big "roots(%ln::)".  At the beginning of the function, when we filter out
         roots that already meet the phase criteria, the *definition* of meeting the
         phase criteria is "not being a descendant of an existing root".  Therefore,
         by definition none of the new roots we are processing are descendants of an
         existing root.
      
      3) If two nodes are passed in as input, and one node is an ancestor of the other
         (and therefore the later node should not be a root), this is still caught by
         the 'roots(%ln::)' revset. So there's no chance of an extra root being
         introduced that way either.
      e3611881
  4. Nov 12, 2015
  5. Nov 02, 2015
    • Pierre-Yves David's avatar
      format: introduce 'format.usegeneraldelta` · dfab6edb
      Pierre-Yves David authored
      This option will make repositories created as general delta by default but will
      not make Mercurial aggressively recompute deltas for all incoming bundle.
      Instead, the delta contained in the bundle will be used. This will allow us to
      start having general delta repositories created everywhere without triggering
      massive recomputation costs for all new clients cloning from old servers.
      dfab6edb
    • Pierre-Yves David's avatar
      scmutil: extract general delta config handling in a function · e40af07e
      Pierre-Yves David authored
      General delta is currently controlled by a single option, we will introduce a
      new one in the next changeset.
      
      We extract the logic in a function while it is simple.
      e40af07e
  6. Nov 10, 2015
  7. Nov 08, 2015
    • Matt Harbison's avatar
      test-convert-git: silence commit output for stablity · 7e8912db
      Matt Harbison authored
      When running the tests with 1.7.7.6, I get 'files' and 'insertions' instead of
      the singular forms, and there is also an additional '0 deletions(-)' at the end.
      Since this doesn't seem important to the test, silence it.
      7e8912db
    • Matt Harbison's avatar
      rebase: preserve the 'intermediate-source' attribute of grafts · 7ffebbdc
      Matt Harbison authored
      Preserving the 'source' attribute of grafts started with a69a77a80900, which
      predates the introduction of 'intermediate-source' in 51930a7180bd by a year and
      a half.  It looks like not preserving this was an oversight.
      
      On a related note, notice how the source value of 32af76 is no longer visible in
      the graph above this test.  Is it reasonable to import the sha1 translation from
      evolve.py:relocate() into scmutil or similar, and use that to fixup these
      attributes as well as the commit message?  (I realize that evolve is still
      experimental, but I don't see a way to do this from the evolve extension.)
      7ffebbdc
  8. Nov 11, 2015
  9. Nov 04, 2015
  10. Nov 11, 2015
  11. Nov 10, 2015
  12. Nov 09, 2015
  13. Nov 07, 2015
    • Anton Shestakov's avatar
      dockerlib: allow non-unique uid and gid of $DBUILDUSER (issue4657) · 271a8020
      Anton Shestakov authored
      There are make targets for building mercurial packages for various
      distributions using docker. One of the preparation steps before building is to
      create inside the docker image a user with the same uid/gid as the current user
      on the host system, so that the resulting files have appropriate
      ownership/permissions.
      
      It's possible to run `make docker-<distro>` as a user with uid or gid that is
      already present in a vanilla docker container of that distibution. For example,
      issue4657 is about failing to build fedora packages as a user with uid=999 and
      gid=999 because these ids are already used in fedora, and groupadd fails.
      useradd would fail too, if the flow ever got to it (and there was a user with
      such uid already).
      
      A straightforward (maybe too much) way to fix this is to allow non-unique uid
      and gid for the new user and group that get created inside the image. I'm not
      sure of the implications of this, but marmoute encouraged me to try and send
      this patch for stable.
      271a8020
  14. Nov 09, 2015
    • Mateusz Kwapich's avatar
      dirstate: fix filefoldmap incosistency on file delete · 663eff02
      Mateusz Kwapich authored
      The _filefoldmap is not updated in when files are deleted from dirstate. In the
      case where the file with the same but differently cased name is added afterwards
      it renders _filefoldmap incorrect.  Those steps must occur to for a problem to
      reproduce:
       - call status (with listunknown=True),
       - update working rectory to a commit which does a casefolding change (A -> a)
       - call status again (it will show the file "a" as deleted)
      
      Unfortunately I'm unable to write a test for it because I don't know any
      core-mercurial command able to reproduce those steps.
      
      The bug was originally spotted when hgwatchman was enabled. It caused the
      changeset contents change during hg rebase (one file unrelarted to changeset
      was deleted in it after rebase).
      
      The hgwatchman is able to hit it because when hgignore changes the hgwatchmans
      overridestatus is calling original status with listunknown=True.
      663eff02
    • Steve Borho's avatar
      wix: style-coal.css has been renamed · 29ca5b76
      Steve Borho authored
      29ca5b76
    • Matt Mackall's avatar
      merge with stable · 8b2fbe3f
      Matt Mackall authored
      8b2fbe3f
  15. Nov 05, 2015
  16. Nov 06, 2015
  17. Nov 05, 2015
  18. Nov 07, 2015
Loading