Skip to content
Snippets Groups Projects
  1. Jun 21, 2017
    • Jun Wu's avatar
      patch: rewrite reversehunks (issue5337) · 66117dae87f9
      Jun Wu authored
      The old reversehunks code accesses "crecord.uihunk._hunk", which is the raw
      recordhunk without crecord selection information, therefore "revert -i"
      cannot revert individual lines, aka. issue5337.
      
      The patch rewrites related logic to return the right reverse hunk for
      revert. Namely,
      
       1. "fromline" and "toline" are correctly swapped [1]
       2. crecord.uihunk generates a correct reverse hunk [2]
      
      Besides, reversehunks(hunks) will no longer modify its input "hunks", which
      is more expected.
      
      [1]: To explain why "fromline" and "toline" need to be swapped, take the
           following example:
      
        $ cat > a <<EOF
        > 1
        > 2
        > 3
        > 4
        > EOF
      
        $ cat > b <<EOF
        > 2
        > 3
        > 5
        > EOF
      
        $ diff a b
        1d0   <---- "1" is "fromline" and "0" is "toline"
        < 1         and they are swapped if diff from the reversed direction
        4c3             |
        < 4             |
        ---             |
        > 5             |
                        |
        $ diff b a      |
        0a1   <---------+
        > 1
        3c4   <---- also "4c3" gets swapped to "3c4"
        < 5
        ---
        > 4
      
      [2]: This is a bit tricky.
      
      For example, given a file which is empty in working parent but has 3 lines
      in working copy, and the user selection:
      
          select hunk to discard
          [x] +1
          [ ] +2
          [x] +3
      
      The user intent is to drop "1" and "3" in working copy but keep "2", so the
      reverse patch would be something like:
      
              -1
               2 (2 is a "context line")
              -3
      
      We cannot just take all selected lines and swap "-" and "+", which will be:
      
              -1
              -3
      
      That patch won't apply because of "2". So the correct way is to insert "2"
      as a "context line" by inserting it first then deleting it:
      
              -2
              +2
      
      Therefore, the correct revert patch is:
      
              -1
              -2
              +2
              -3
      
      It could be reordered to look more like a common diff hunk:
      
              -1
              -2
              -3
              +2
      
      Note: It's possible to return multiple hunks so there won't be lines like
      "-2", "+2". But the current implementation is much simpler.
      
      For deletions, like the working parent has "1\n2\n3\n" and it was changed to
      empty in working copy:
      
          select hunk to discard
          [x] -1
          [ ] -2
          [x] -3
      
      The user intent is to drop the deletion of 1 and 3 (in other words, keep
      those lines), but still delete "2".
      
      The reverse patch is meant to be applied to working copy which is empty.
      So the patch would be:
      
              +1
              +3
      
      That is to say, there is no need to special handle the unselected "2" like
      the above insertion case.
      66117dae87f9
    • Pierre-Yves David's avatar
      profiling: cope with configwith default value handling changes · 41b081ac2145
      Pierre-Yves David authored
      Changeset 6ff6eb33f353 change 'configwith' behavior so that the default value is
      run through the conversion function. In parallel a new user of 'configwith' got
      introduced unaware of this coming behavior change. This broke profiling.
      
      We resolve the situation by having the new conversion function cope with a
      default value already using the right type.
      41b081ac2145
  2. Jun 20, 2017
    • Martin von Zweigbergk's avatar
      py3: catch StopIteration from next() in generatorset · 27ba0d8dc26c
      Martin von Zweigbergk authored
      IIUC, letting the StopIteration through would not cause any bugs, but
      not doing it makes the test-py3-commands.t pass.
      
      I have also diligently gone through all uses of next() in our code
      base. They either:
      
       * are not called from a generator
       * pass a default value to next()
       * catch StopException
       * work on infinite iterators
       * request a fixed number of items that matches the generated number
       * are about batching in wireproto which I didn't quite follow
      
      I'd appreciate if Augie or someone else could take a look at the
      wireproto batching and convince themselves that the next(batchable)
      calls there will not raise a StopIteration.
      27ba0d8dc26c
  3. Jun 21, 2017
  4. Jun 20, 2017
  5. Jun 21, 2017
    • Jun Wu's avatar
      shelve: allow unlimited shelved changes per name · 4107eb8a5648
      Jun Wu authored
      Previously, there is a 100 changes limit per name (bookmark or named
      branch). And the user will get "too many shelved changes named %s" when they
      are trying to shelve the 101th change. I hit that error message today.
      
      This limit was introduced by the shelve extension since the beginning.
      The function generating the names was called "gennames", under
      "getshelvename".
      
      There is another "gennames" under "backupfilename":
      
          def backupfilename(self):
              def gennames(base):
                  yield base
                  base, ext = base.rsplit('.', 1)
                  for i in itertools.count(1):
                      yield '%s-%d.%s' % (base, i, ext)
      
      "itertools.count" is an endless counter.
      
      Since the other "gennames" generates unlimited number of names, and the
      changeset introducing the limit (49d4919d21c2) does not say why the limit
      is useful. It seems safe to just remove the limit.
      
      The format "%02d" was kept intentionally so existing shelved changes won't
      break.
      4107eb8a5648
  6. Jun 17, 2017
  7. Jun 20, 2017
    • Martin von Zweigbergk's avatar
      clonebundle: update hook arguments (BC) · 067173e3c8a6
      Martin von Zweigbergk authored
      By calling applybundle() with 'clonebundles' and the url instead of
      calling processbundle(), the hooks will get different arguments:
      HG_SOURCE will be 'clonebundles' instead of 'bundle2' and HG_URL will
      be the url instead of 'bundle2'. This is consistent with the bundle1
      behavior and seems like a bug fix, but I'm marking it BC anyway.
      067173e3c8a6
  8. Jun 11, 2017
    • Sean Farley's avatar
      commands: move checkconflict to bookmarks module · 4f0a7f604449
      Sean Farley authored
      Again, commands.bookmark is getting too large. checkconflict already has
      a lot of state and putting it in the bmstore makes more sense than
      having it as a closure. This also allows extensions a place to override
      this behavior.
      
      While we're here, add a documentation string because, well, we should be
      documenting more of our methods.
      4f0a7f604449
    • Sean Farley's avatar
      commands: move checkformat to bookmarks module · 70661eeb8ddb
      Sean Farley authored
      commands.bookmark has grown quite large with two closures already. Let's
      split this up (and in the process allow extensions to override the
      default behavior).
      70661eeb8ddb
  9. Jun 20, 2017
    • Danek Duvall's avatar
      tests: tell pip not to check for a newer version · b5305a499dfc
      Danek Duvall authored
      pip will check to see if it's the latest version, and complain if it isn't.
      The --no-index flag implies the --disable-pip-version-check flag, and makes
      the warning (and any associated network activity) go away.
      b5305a499dfc
  10. Apr 22, 2017
  11. Jun 17, 2017
  12. Apr 22, 2017
  13. Jun 20, 2017
  14. Jun 19, 2017
  15. Jun 04, 2017
    • Gregory Szorc's avatar
      tests: removed ReportedTest exception · 750c3b1bb8a3
      Gregory Szorc authored
      The only call site called addFailure before raising, which is
      exactly what the failure exception handler does. So this
      complexity is not needed.
      
      We have test coverage of this "server failed to start" scenario
      and nothing appeared to change.
      750c3b1bb8a3
    • Gregory Szorc's avatar
      tests: remove support for warned tests · 5af78c524f34
      Gregory Szorc authored
      The previous changeset removed the last caller of addWarn(). So,
      we rip out that method and all the code related to tracking warned
      tests in the results system.
      
      There was even a comment saying we may want to fold warned tests into
      the "failed" state, which is what the previous changeset did.
      5af78c524f34
  16. Jun 20, 2017
Loading