Skip to content
Snippets Groups Projects
  1. Oct 13, 2015
    • Katsunori FUJIWARA's avatar
      localrepo: restore dirstate to one before rollbacking if not parent-gone · e077ce385609
      Katsunori FUJIWARA authored
      'localrepository.rollback()' explicilty restores dirstate, only if at
      least one of current parents of the working directory is removed at
      rollbacking (a.k.a "parent-gone").
      
      After DirstateTransactionPlan, 'dirstate.write()' will cause marking
      '.hg/dirstate' as a file to be restored at rollbacking.
      
          https://mercurial.selenic.com/wiki/DirstateTransactionPlan
      
      Then, 'transaction.rollback()' restores '.hg/dirstate' regardless of
      parents of the working directory at that time, and this causes
      unexpected dirstate changes if not "parent-gone" (e.g.  "hg update" to
      another branch after "hg commit" or so, then "hg rollback").
      
      To avoid such situation, this patch restores dirstate to one before
      rollbacking if not "parent-gone".
      
        before:
          b1. restore dirstate explicitly, if "parent-gone"
      
        after:
          a1. save dirstate before actual rollbacking via dirstateguard
          a2. restore dirstate via 'transaction.rollback()'
          a3. if "parent-gone"
              - discard backup (a1)
              - restore dirstate from 'undo.dirstate'
          a4. otherwise, restore dirstate from backup (a1)
      
      Even though restoring dirstate at (a3) after (a2) seems redundant,
      this patch keeps this existing code path, because:
      
        - it isn't ensured that 'dirstate.write()' was invoked at least once
          while transaction running
      
          If not, '.hg/dirstate' isn't restored at (a2).
      
          In addition to it, rude 3rd party extension invoking
          'dirstate.write()' without 'repo' while transaction running (see
          subsequent patches for detail) may break consistency of a file
          backup-ed by transaction.
      
        - this patch mainly focuses on changes for DirstateTransactionPlan
      
          Restoring dirstate at (a3) itself should be cheaper enough than
          rollbacking itself. Redundancy will be removed in next step.
      
      Newly added test is almost meaningless at this point. It will be used
      to detect regression while implementing delayed dirstate write out.
      e077ce385609
    • Katsunori FUJIWARA's avatar
      parsers: make pack_dirstate take now in integer for consistency · 3111b45a2bbf
      Katsunori FUJIWARA authored
      On recent OS, 'stat.st_mtime' has a double precision floating point
      value to represent nano seconds, but it is not wide enough for actual
      file timestamp: nowadays, only 52 - 32 = 20 bit width is available for
      decimal places in sec.
      
      Therefore, casting it to 'int' may cause unexpected result. See also
      changeset 13272104bb07 fixing issue4836 for detail.
      
      For example, changed file A may be treated as "clean" unexpectedly in
      steps below. "rounded now" is the value gotten by rounding via
      'int(st.st_mtime)' or so.
      
          ---------------------+--------------------+------------------------
          "now"                |                    | timestamp of A (time_t)
          float  rounded time_t| action             | FS       dirstate
          ------ ------- ------+--------------------+-------- ---------------
          N+.nnn   N       N   |                    | ---      ---
                               | update file A      |  N
                               | dirstate.normal(A) |           N
          N+.999   N+1     N   |                    |
                               | dirstate.write()   |           N (*1)
                               |    :               |
                               | change file A      |  N
                               |    :               |
          N+1.00   N+1    N+1  |                    |
                               | "hg status" (*2)   |  N        N
          ------ ------- ------+--------------------+-------- ---------------
      
      Timestamp N of A in dirstate isn't dropped at (*1), because "rounded
      now" is N+1 at that time, even if 'st_mtime' in 'time_t' is still N.
      
      Then, file A is unexpectedly treated as "clean" at (*2) in this case.
      
      For consistent handling of 'stat.st_mtime', this patch makes
      'pack_dirstate()' take 'now' argument not in floating point but in
      integer.
      
      This patch makes 'PyArg_ParseTuple()' in 'pack_dirstate()' use format
      'i' (= checking type mismatch or overflow), even though it is ensured
      that 'now' is in the range of 32bit signed integer by masking with
      '_rangemask' (= 0x7fffffff) on caller side.
      
      It should be cheaper enough than packing itself, and useful to
      detect that legacy code invokes 'pack_dirstate()' with 'now' in
      floating point value.
      3111b45a2bbf
  2. Sep 29, 2015
    • Pierre-Yves David's avatar
      destupdate: include the 'check' logic · ae5f7be2b4ab
      Pierre-Yves David authored
      After moving logic from 'merge.update' into 'destutil.destupdate', we are now
      moving logic from 'command.update' in 'destutil.destupdate'. This will make the
      function actually useful in predicting (and altering) the update behavior.
      ae5f7be2b4ab
  3. Oct 05, 2015
    • Pierre-Yves David's avatar
      destupdate: move the check related to the "clean" logic in the function · 45b86dbabbda
      Pierre-Yves David authored
      We want this function to exactly predict the behavior for update. Moreover, we
      would like to remove all high level behavior logic out of the merge module so
      this is a step forward.
      
      Now that the 'destupdate' function both compute and validate the destination, we
      can directly use it at the command level, ensuring that the 'hg update' command
      never call 'merge.update' without a defined destination. This is a first (but
      significant) step toward having 'merge.update' always feed with a properly
      validated destination and free of high level logic.
      45b86dbabbda
  4. Oct 12, 2015
    • Mads Kiilerich's avatar
      largefiles: better handling of merge of largefiles that not are available · 832c98d79587
      Mads Kiilerich authored
      Before, when merging revisions with missing largefiles, the missing largefiles
      would be fetched as a part of the merge. If that failed (for example because
      the main repository temporarily was unavailable), the largefile would be left
      missing. However, the next commit would abort and (seemed to) fail when
      markcommitted tried to mark the standin file as normal and thus had to hash the
      largefile that didn't exist. (Actually, the commit would succeed but the
      largefile update that follows right after the commit transaction would abort -
      quite confusing.)
      
      To fix that, make sure that synclfdirstate only marks files as normal if they
      actually exist.
      832c98d79587
    • Pierre-Yves David's avatar
      patchbomb: check that targets exist at the publicurl · dca161728dc9
      Pierre-Yves David authored
      Advertising that the patch are available to be pulled requires that to be true.
      So we check revision availability on the remote before sending any email.
      dca161728dc9
    • Mads Kiilerich's avatar
      windows: read all global config files, not just the first (issue4491) (BC) · adae8928fe09
      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.
      adae8928fe09
  5. Oct 09, 2015
    • Ryan McElroy's avatar
      strip: factor out revset calculation for strip -B · bcace0fbb4c8
      Ryan McElroy authored
      This will allow reusing it in evolve and overriding it in other extensions.
      bcace0fbb4c8
    • Gregory Szorc's avatar
      clonebundles: support for seeding clones from pre-generated bundles · 5a95fe44121d
      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.
      5a95fe44121d
  6. Sep 29, 2015
  7. Oct 12, 2015
  8. Oct 09, 2015
    • Siddharth Agarwal's avatar
      simplemerge: move conflict warning message to filemerge · ef1eb6df7071
      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.
      ef1eb6df7071
  9. Oct 11, 2015
  10. Oct 12, 2015
  11. Oct 08, 2015
  12. Oct 12, 2015
  13. Oct 11, 2015
  14. Oct 08, 2015
    • Mads Kiilerich's avatar
      context: don't hex encode all unknown 20 char revision specs (issue4890) · a3fcc8e3136b
      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.
      a3fcc8e3136b
  15. Oct 12, 2015
    • Pierre-Yves David's avatar
      discovery: put trivial branch first · 517ffec37dee
      Pierre-Yves David authored
      Having the simple and tiny branch of the conditional first help readability. The
      "else" that appears after a screen of code is harder to relate to a conditional.
      517ffec37dee
  16. Oct 09, 2015
  17. Oct 12, 2015
  18. Oct 09, 2015
  19. Oct 12, 2015
  20. Oct 07, 2015
    • Emanuele Giaquinta's avatar
      cvsps: fix computation of parent revisions when log caching is on · c60dfcc0abf2
      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.
      c60dfcc0abf2
  21. Oct 06, 2015
Loading