Skip to content
Snippets Groups Projects
  1. Jun 25, 2015
  2. Jul 17, 2015
  3. Jun 25, 2015
  4. Jul 18, 2015
    • Gregory Szorc's avatar
      changegroup: compute seen files as changesets are added (issue4750) · 2406e2ba
      Gregory Szorc authored
      Before this patch, addchangegroup() would walk the changelog and compute
      the set of seen files between applying changesets and applying
      manifests. When cloning large repositories such as mozilla-central,
      this consumed a non-trivial amount of time. On my MBP, this walk takes
      ~10s. On a dainty EC2 instance, this was measured to take ~125s! On the
      latter machine, this delay was enough for the Mercurial server to
      disconnect the client, thinking it had timed out, thus causing a clone
      to abort.
      
      This patch enables the changelog to compute the set of changed files as
      new revisions are added. By doing so, we:
      
      * avoid a potentially heavy computation between changelog and manifest
        processing by spreading the computation across all changelog additions
      * avoid extra reads from the changelog by operating on the data as it is
        added
      
      The downside of this is that the add revision callback does result in
      extra I/O. Before, we would perform a flush (and subsequent read to
      construct the full revision) when new delta chains were created. For
      changelogs, this is typically every 2-4 revisions. Using the callback
      guarantees there will be a flush after every added revision *and* an
      open + read of the changelog to obtain the full revision in order to
      read the added files. So, this increases the frequency of these
      operations by the average chain length. In the future, the revlog
      should be smart enough to know how to read revisions that haven't been
      flushed yet, thus eliminating this extra I/O.
      
      On my MBP, the total CPU times for an `hg unbundle` with a local
      mozilla-central gzip bundle containing 251,934 changesets and 211,065
      files did not have a statistically significant change with this patch,
      holding steady around 360s. So, the increased revlog flushing did not
      have an effect.
      
      With this patch, there is no longer a visible pause between applying
      changeset and manifest data. Before, it sure felt like Mercurial was
      lethargic making this transition. Now, the transition is nearly
      instantaneous, giving the impression that Mercurial is faster. Of course,
      eliminating this pause means that the potential for network disconnect due
      to channel inactivity during the changelog walk is eliminated as well.
      And that is the impetus behind this change.
      2406e2ba
    • Gregory Szorc's avatar
      revlog: add support for a callback whenever revisions are added · 00e3f909
      Gregory Szorc authored
      A subsequent patch will add a feature that performs iterative
      computation as changesets are added from a changegroup. To facilitate
      this type of processing in a generic manner, we add a mechanism for
      calling a function whenever a revision is added via revlog.addgroup().
      
      There are potential performance concerns with this callback, as using it
      will flush the revlog after every revision is added.
      00e3f909
  5. Jul 17, 2015
    • Laurent Charignon's avatar
      crecord: throws error instead of crashing for large diffs · d68544b6
      Laurent Charignon authored
      Before this patch, crecord was crashing for large diffs
      (30k lines on my laptop). This patch catches the exception raised in that case
      and use the error reporting mechanism introduced in the previous patch for
      notifying the user of the issue. It is not possible to add a test for that for
      now as we don't yet have full blown ui tests for the curses interface.
      d68544b6
    • Laurent Charignon's avatar
      crecord: add error reporting for failure in curses interface initialization · 701d8c36
      Laurent Charignon authored
      Before this patch, we couldn't report to the user any error that occurred:
      - after we enabled the curses interface but
      - before the interface is set up and drawn
      This patch, provides a way to set errors that happens during the initialization
      of the interface and log them once the curses interface has been displayed.
      701d8c36
  6. Jul 05, 2015
  7. Jul 06, 2015
  8. Jul 05, 2015
    • Yuya Nishihara's avatar
      parser: resolve ambiguity where both prefix and primary actions are defined · 43a8a87f
      Yuya Nishihara authored
      If both actions are defined, a primary-expression action is accepted only if
      the next token never starts new term. For example,
      
        parsed as primary expression:
        ":"   # next token 'end' has no action
        "(:)" # next token ')' has no action
        ":+y" # next token '+' is infix operator
      
        parsed as prefix operator:
        ":y"  # next token 'y' is primary expression
        ":-y" # next token '-' is prefix operator
      
      This is mostly the same resolution as the infix/suffix rules.
      43a8a87f
    • Yuya Nishihara's avatar
      parser: separate actions for primary expression and prefix operator · e71e5629
      Yuya Nishihara authored
      This will allow us to define both a primary expression, ":", and a prefix
      operator, ":y". The ambiguity will be resolved by the next patch.
      
      Prefix actions in elements table are adjusted as follows:
      
        original prefix      primary  prefix
        -----------------    -------- -----------------
        ("group", 1, ")") -> n/a      ("group", 1, ")")
        ("negate", 19)    -> n/a      ("negate", 19)
        ("symbol",)       -> "symbol" n/a
      e71e5629
  9. Jul 17, 2015
  10. Jul 15, 2012
  11. Jul 12, 2012
    • Matt Harbison's avatar
      extdiff: use archiver to take snapshots of committed revisions · 68822b7c
      Matt Harbison authored
      This is the last step before supporting extdiff -S.  It maintains the existing
      behavior of diffing the largefile standins instead of the largefiles themselves.
      Note however that the standins are not updated immediately upon modification, so
      uncommitted largefile changes are ignored, as they previously were, even with
      the diff command.
      68822b7c
  12. Jul 12, 2015
    • Matt Harbison's avatar
      largefiles: allow the archiving of largefiles to be disabled · 7699d321
      Matt Harbison authored
      There are currently no users of this, but it is a necessary step before
      converting extdiff to use archive.  It may be useful to add an argument to
      extdiff in the future and allow largefiles to be diffed, but archiving
      largefiles can have significant overhead and may not be very diffable, so
      archiving them by default seems wrong.
      
      It is a mystery to me why the lfstatus attribute needs to be set on the
      unfiltered repo.  However if it is set on the filtered repo instead (and the
      filtered repo is passed to the original command), the lfstatus attribute is
      False in the overrides for archival.archive() and hgsubrepo.archive() when
      invoking the archive command.  This smells like the buggy status behavior (see
      67d63ec85eb7, which was reverted in df463ca0adef).  Neither the status nor
      summary commands have this weird behavior in their respective overrides.
      7699d321
  13. Jul 16, 2015
    • Yuya Nishihara's avatar
      parsers: fix buffer overflow by invalid parent revision read from revlog · 82d6a35c
      Yuya Nishihara authored
      If revlog file is corrupted, it can have parent pointing to invalid revision.
      So we should validate it before updating nothead[], phases[], seen[], etc.
      Otherwise it would cause segfault at best.
      
      We could use "rev" instead of "maxrev" as upper bound, but I think the explicit
      "maxrev" can clarify that we just want to avoid possible buffer overflow
      vulnerability.
      82d6a35c
    • Laurent Charignon's avatar
      histedit: mark temporary commits as obsolete when allowed to · ebb5bb9b
      Laurent Charignon authored
      Before this patch, we were stripping temporary commits at the end of a histedit
      whether it was successful or not. If we can create obs markers, we should
      create them instead of stripping because it is faster and safer.
      ebb5bb9b
Loading