Skip to content
Snippets Groups Projects
  1. Oct 12, 2015
    • Mads Kiilerich's avatar
      windows: read all global config files, not just the first (issue4491) (BC) · adae8928
      Mads Kiilerich authored
      On windows, hgrc.d/*.rc would not be read if mercurial.ini was found. That was
      far from obvious from the documentation and different from the behavior on
      posix systems.
      
      As a consequence of this, TortoiseHg cacert configuration placed in hgrc.d
      would not be read if an old global mercurial.ini still existed.
      
      "hg config -g" could also crash when no global configuration files could be
      found.
      
      Instead, make windows behave like posix and read all global configuration
      files.
      
      The documentation was in a way right that individual config settings in the
      global Mercurial.ini would override settings from for example .hgrc.d\*.rc, but
      only because the .d files not would be read at all if a Mercurial.ini was
      found. The ordering in the documentation is thus changed to match the code.
      adae8928
  2. Oct 09, 2015
    • Ryan McElroy's avatar
      strip: factor out revset calculation for strip -B · bcace0fb
      Ryan McElroy authored
      This will allow reusing it in evolve and overriding it in other extensions.
      bcace0fb
    • Gregory Szorc's avatar
      clonebundles: support for seeding clones from pre-generated bundles · 5a95fe44
      Gregory Szorc authored
      Cloning can be an expensive operation for servers because the server
      generates a bundle from existing repository data at request time. For
      a large repository like mozilla-central, this consumes 4+ minutes
      of CPU time on the server. It also results in significant network
      utilization. Multiplied by hundreds or even thousands of clients and
      the ensuing load can result in difficulties scaling the Mercurial server.
      
      Despite generation of bundles being deterministic until the next
      changeset is added, the generation of bundles to service a clone request
      is not cached. Each clone thus performs redundant work. This is
      wasteful.
      
      This patch introduces the "clonebundles" extension and related
      client-side functionality to help alleviate this deficiency. The
      client-side feature is behind an experimental flag and is not enabled by
      default.
      
      It works as follows:
      
      1) Server operator generates a bundle and makes it available on a
         server (likely HTTP).
      2) Server operator defines the URL of a bundle file in a
         .hg/clonebundles.manifest file.
      3) Client `hg clone`ing sees the server is advertising bundle URLs.
      4) Client fetches and applies the advertised bundle.
      5) Client performs equivalent of `hg pull` to fetch changes made since
         the bundle was created.
      
      Essentially, the server performs the expensive work of generating a
      bundle once and all subsequent clones fetch a static file from
      somewhere. Scaling static file serving is a much more manageable
      problem than scaling a Python application like Mercurial. Assuming your
      repository grows less than 1% per day, the end result is 99+% of CPU
      and network load from clones is eliminated, allowing Mercurial servers
      to scale more easily. Serving static files also means data can be
      transferred to clients as fast as they can consume it, rather than as
      fast as servers can generate it. This makes clones faster.
      
      Mozilla has implemented similar functionality of this patch on
      hg.mozilla.org using a custom extension. We are hosting bundle files in
      Amazon S3 and CloudFront (a CDN) and have successfully offloaded
      >1 TB/day in data transfer from hg.mozilla.org, freeing up significant
      bandwidth and CPU resources. The positive impact has been stellar and
      I believe it has proved its value to be included in Mercurial core. I
      feel it is important for the client-side support to be enabled in core
      by default because it means that clients will get faster, more reliable
      clones and will enable server operators to reduce load without
      requiring any client-side configuration changes (assuming clients are
      up to date, of course).
      
      The scope of this feature is narrowly and specifically tailored to
      cloning, despite "serve pulls from pre-generated bundles" being a valid
      and useful feature. I would eventually like for Mercurial servers to
      support transferring *all* repository data via statically hosted files.
      You could imagine a server that siphons all pushed data to bundle files
      and instructs clients to apply a stream of bundles to reconstruct all
      repository data. This feature, while useful and powerful, is
      significantly more work to implement because it requires the server
      component have awareness of discovery and a mapping of which changesets
      are in which files. Full, clone bundles, by contrast, are much simpler.
      
      The wire protocol command is named "clonebundles" instead of something
      more generic like "staticbundles" to leave the door open for a new, more
      powerful and more generic server-side component with minimal backwards
      compatibility implications. The name "bundleclone" is used by Mozilla's
      extension and would cause problems since there are subtle differences
      in Mozilla's extension.
      
      Mozilla's experience with this idea has taught us that some form of
      "content negotiation" is required. Not all clients will support all
      bundle formats or even URLs (advanced TLS requirements, etc). To ensure
      the highest uptake possible, a server needs to advertise multiple
      versions of bundles and clients need to be able to choose the most
      appropriate from that list one. The "attributes" in each
      server-advertised entry facilitate this filtering and sorting. Their
      use will become apparent in subsequent patches.
      
      Initial inspiration and credit for the idea of cloning from static files
      belongs to Augie Fackler and his "lookaside clone" extension proof of
      concept.
      5a95fe44
  3. Sep 29, 2015
  4. Oct 12, 2015
  5. Oct 09, 2015
    • Siddharth Agarwal's avatar
      simplemerge: move conflict warning message to filemerge · ef1eb6df
      Siddharth Agarwal authored
      The current output for a failed merge with conflict markers looks something like:
      
        merging foo
        warning: conflicts during merge.
        merging foo incomplete! (edit conflicts, then use 'hg resolve --mark')
        merging bar
        warning: conflicts during merge.
        merging bar incomplete! (edit conflicts, then use 'hg resolve --mark')
      
      We're going to change the way merges are done to perform all premerges before
      all merges, so that the output above would look like:
      
        merging foo
        merging bar
        warning: conflicts during merge.
        merging foo incomplete! (edit conflicts, then use 'hg resolve --mark')
        warning: conflicts during merge.
        merging bar incomplete! (edit conflicts, then use 'hg resolve --mark')
      
      The 'warning: conflicts during merge' line has no context, so is pretty
      confusing.
      
      This patch will change the future output to:
      
        merging foo
        merging bar
        warning: conflicts while merging foo! (edit, then use 'hg resolve --mark')
        warning: conflicts while merging bar! (edit, then use 'hg resolve --mark')
      
      The hint on how to resolve the conflicts makes this a bit unwieldy, but solving
      that is tricky because we already hint that people run 'hg resolve' to retry
      unresolved merges. The 'hg resolve --mark' mostly applies to conflict marker
      based resolution.
      ef1eb6df
  6. Oct 11, 2015
  7. Oct 12, 2015
  8. Oct 08, 2015
  9. Oct 12, 2015
  10. Oct 11, 2015
  11. Oct 08, 2015
    • Mads Kiilerich's avatar
      context: don't hex encode all unknown 20 char revision specs (issue4890) · a3fcc8e3
      Mads Kiilerich authored
      d3908c911d5e introduced nice hexified display of missing nodes. It did however
      also make missing 20 character revision specifications be shown as hex - very
      confusing.
      
      Users are often wrong and somehow specify revisions that don't exist. Nodes
      will however rarely be missing ... and they will only look like a user provided
      revision specification and be all ascii in 1 of 4*10**9.
      
      With this change, missing revisions will only be hexified if they really look
      like binary nodes. This change will thus improve the error reporting UI in the
      common case and only very rarely make it confusing in the opposite direction of
      how it was before.
      a3fcc8e3
  12. Oct 12, 2015
  13. Oct 09, 2015
  14. Oct 12, 2015
  15. Oct 09, 2015
  16. Oct 12, 2015
  17. Oct 07, 2015
    • Emanuele Giaquinta's avatar
      cvsps: fix computation of parent revisions when log caching is on · c60dfcc0
      Emanuele Giaquinta authored
      cvsps computes the parent revisions of log entries by walking the cvs log
      sorted by (rcs, revision) and by iteratively maintaining a 'versions'
      dictionary which maps a (rcs, branch) pair onto the last revision seen for that
      pair. When log caching is on and a log cache exists, cvsps fails to set the
      parent revisions of new log entries because it does not iterate over the log
      cache in the parents computation. A complication is that a file rcs can change
      (move to/from the attic), with respect to its value in the log cache, if the
      file is removed/added back. This patch adds an iteration over the log cache to
      update the rcs of cached log entries, if changed, and to properly populate the
      'versions' dictionary.
      c60dfcc0
  18. Oct 06, 2015
  19. Oct 11, 2015
  20. Oct 08, 2015
  21. Oct 06, 2015
Loading