Skip to content
Snippets Groups Projects
  1. Feb 13, 2012
    • Patrick Mézard's avatar
      patch: fuzz more aggressively to match patch(1) behaviour · 0e0060bf2f44
      Patrick Mézard authored
      The previous code was assuming a default context of 3 lines. When fuzzing, it
      would take this value in account to reduce the amount of removed line from
      hunks top or bottom. For instance, if a hunk has only 2 lines of bottom
      context, fuzzing with fuzz=1 would do nothing and with fuzz=2 it would remove
      one of those lines. A hunk with one line of bottom context could not be fuzzed
      at all.  patch(1) has apparently no such restrictions and takes the fuzz level
      at face value.
      
      - test-import.t: fuzz/offset changes at the beginning of file are explained by
        the new fuzzing behaviour and match patch(1) ones. Patching locations are
        different but those of my patch(1) do not make a lot of sense right now
        (patched output are the same)
      
      - test-import-bypass.t: more agressive fuzzing makes a patching supposed to
        fail because of context, succeed. Change the diff to avoid this.
      
      - test-mq-merge.t: more agressive fuzzing would allow the merged patch to apply
        with fuzz, but fortunately we disallow this behaviour. The new output is
        kept.
      
      I have not enough experience with patch(1) fuzzing to know whether aligning our
      implementation on it is a good or bad idea. Until now, it has been the
      implementation reference. For instance, "qpush" tolerates fuzz (test-mq-merge.t
      runs the special case of pushing merge revisions where fuzzing is forbidden).
      0e0060bf2f44
    • Patrick Mézard's avatar
      patch: fix fuzzing of hunks without previous lines (issue3264) · b0c7525f826d
      Patrick Mézard authored
      When applying hunks such as:
      
        @@ -2,1 +2,2 @@
         context
        +change
      
      fuzzing would empty the "old" block and make patchfile.apply() traceback.
      Instead, we apply the new block at specified location without testing.
      
      The "bottom hunk" test was removed as patch(1) has no problem applying hunk
      with no context in the middle of a file.
      b0c7525f826d
    • Patrick Mézard's avatar
      patch: make hunk.fuzzit() compute the fuzzed start locations · 9ef3a4a2c6c0
      Patrick Mézard authored
      - It moves hunks processing weirdness where it belongs
      - It helps reusing said weirdness whenever fuzzit() is called, like during the
        actual hunk fuzzing.
      9ef3a4a2c6c0
    • Patrick Mézard's avatar
      patch: fuzz old and new lines at the same time · ccba74472af2
      Patrick Mézard authored
      In theory, the fuzzed offsets for old and new lines should be exactly the same
      as they are based on hunk parsing. Make it true in practice.
      ccba74472af2
  2. Feb 14, 2012
  3. Feb 15, 2012
    • Patrick Mézard's avatar
      convert: tolerate spaces between splicemap parent ids (issue3203) · d554a3dcae5a
      Patrick Mézard authored
      Splicemap lines are documented in hg help convert like:
      
        key parent1, parent2
      
      but parsed like:
      
        key, parents = line.strip().rsplit(' ', 1)
        parents = parents.replace(',', ' ').split()
      
      The rsplit() call was introduced to handle spaces in keys for the generic
      mapfile format. Spaces can appear in svn identifiers since they contain path
      components. This logic makes less sense with splicemap since svn identifiers
      can also appear on the right side, even if it is a bit less likely. Given the
      parsing is theorically broken, I would rather follow what is documented already
      and is correct in the main case where all identifiers are hg hashes. Also,
      using svn identifiers in a splicemap sounds difficult as they are not easily
      accessible.
      d554a3dcae5a
    • Idan Kamara's avatar
      test-commandserver: flush stdout · 6ecf5fb2a475
      Idan Kamara authored
      6ecf5fb2a475
    • Idan Kamara's avatar
      localrepo: clear _filecache on rollback (issue3261) · ce0ad184f489
      Idan Kamara authored
      Files are being replaced by rollback but the corresponding data in localrepo
      isn't actually updated for things like bookmarks, phases, etc. Then when
      rollback is done, the cache is updated thinking it has the most up-to-date
      data, where in fact it is still pre-rollback.
      
      We clear _filecache to force everything to be recreated.
      ce0ad184f489
    • Idan Kamara's avatar
      scmutil: update cached copy when filecached attribute is assigned (issue3263) · 236bb604dc39
      Idan Kamara authored
      When assigning a new object to filecached properties, the cached object that
      was kept in the _filecache map was still holding the old object.
      
      By implementing __set__, we track these changes too and update the cached
      copy as well.
      236bb604dc39
    • Idan Kamara's avatar
      cmdserver: invalidate the dirstate when running commands (issue3271) · acfca07a8f26
      Idan Kamara authored
      The dirstate is invalidated separately outside of invalidate() which is
      already being called (other callers of invalidate() seems to suggest the
      separation is there for a reason).
      acfca07a8f26
    • Idan Kamara's avatar
      localrepo: reset _phasesdirty flag after writing · 3f75fb837638
      Idan Kamara authored
      3f75fb837638
  4. Feb 16, 2012
    • Patrick Mézard's avatar
      import: handle git renames and --similarity (issue3187) · d7829b2ecf32
      Patrick Mézard authored
      There is no reason to discard copy sources from the set of files considered by
      addremove(). It was done to handle the case where a first patch would create
      'a' and a second one would move 'a' to 'b'. If these patches were applied with
      --no-commit, 'a' would first be marked as added, then unlinked and dropped from
      the dirstate but still passed to addremove(). A better fix is thus to exclude
      removed files which ends being dropped from the dirstate instead of removed.
      
      Reported by Jason Harris <jason@jasonfharris.com>
      d7829b2ecf32
    • Patrick Mézard's avatar
  5. Feb 15, 2012
    • Katsunori FUJIWARA's avatar
      largefiles: check whether specified patterns are related to largefiles strictly · 41417443b7d0
      Katsunori FUJIWARA authored
      current 'lfiles_repo.status()' implementation examines whether
      specified patterns are related to largefiles in working directory (not
      to STANDIN) or not by NOT-EMPTY-NESS of below list:
      
          [f for f in match.files() if f in lfdirstate]
      
      but it can not be assumed that all in 'match.files()' are file itself
      exactly, because user may only specify part of path to match whole
      under subdirectories recursively.
      
      above examination will mis-recognize such pattern as 'not related to
      largefiles', and executes normal 'status()' procedure. so, 'hg status'
      shows '?'(unknown) status for largefiles in working directory unexpectedly.
      
      this patch examines relation of pattern to largefiles by applying
      'match()' on each entries in lfdirstate and checking wheter there is
      no matched entry.
      
      it may increase cost of examination, because it causes of full scan of
      entries in lfdirstate.
      
      so this patch uses normal for-loop instead of list comprehensions, to
      decrease cost when matching is found.
      41417443b7d0
  6. Feb 10, 2012
  7. Feb 07, 2012
    • Patrick Mézard's avatar
      mq: restore _branchtags() fast path (issue3223) · 20ad8f0512a2
      Patrick Mézard authored
      Since a5917346c72e, mq saves the nodeid of the first applied patch to
      cache/branchheads, which breaks the optimized cache handling introduced in
      fbf8320f25c8. The problem is the revision being committed is appended to
      mqrepo.applied after the commit succeeds, which means mqrepo._branchtags()
      performs a regular update and write the first applied patch to the branch
      cache.
      
      One solution is to set a context variable _committingpatch on the mqrepo while
      it is committing a patch and to take it in account when deciding to fast-path
      mqrepo._branchtags(). Not really elegant but it works.
      
      The changes to test-mq-caches.t reverse changes introduced by a5917346c72e. The
      cache should not have been updated with mq records.
      
      The changes to test-keyword.t are indirectly caused by a5917346c72e.
      
      Reported and analyzed by Yuya Nishihara <yuya@tcha.org>
      
      Notes:
      - qpush still makes a slow path _branchtags() call when checking heads. Maybe
        this can be optimized.
      - be careful when merging this patch in default as secretcommit() was renamed
        newcommit() right after the end of the code freeze.
      20ad8f0512a2
    • Patrick Mézard's avatar
      mq: ensure all mq commits are made with secretcommit() · 24df9338aa01
      Patrick Mézard authored
      Having a common code path helps fixing things globally.
      24df9338aa01
  8. Feb 08, 2012
    • Jim Hague's avatar
      tests: tighten checks for octal escapes in shell printf. · c6c9b83a1e8a
      Jim Hague authored
      printf on AIX default shell ksh (89) says \1 is an invalid escape. It insists
      on at least 2 digits. This causes failures in test-keyword.t and test-status.t.
      
      check-code.py already looks out for \NNN and recommends using Python
      for outputting octal values. Extend the check to \NN and \N and fix up
      resulting failures.
      c6c9b83a1e8a
  9. Feb 06, 2012
  10. Feb 04, 2012
  11. Feb 03, 2012
    • Jim Hague's avatar
      bdiff: fix malloc(0) issue in fixws() · 8134ec8627e7
      Jim Hague authored
      If fixws() is called on a zero-length string, malloc(0) is called and
      expected to return a pointer. Which it does on e.g. Linux. AIX returns
      NULL, which it is also legal, but the malloc() is then assumed to have
      failed. So ensure a valid pointer is always returned.
      8134ec8627e7
  12. Feb 06, 2012
    • Katsunori FUJIWARA's avatar
      forget: show warning messages for forgetting in subrepo correctly · f11eee00c652
      Katsunori FUJIWARA authored
      in 'cmdutil.forget()':
      
         for f in match.files():
             if match.exact(f) or not explicitonly:
                 ....
      
      is equal to:
      
         for f in match.files():
             if True:
                 ....
      
      because 'f' from 'match.files()' should 'match.exact(f)':
      
          - 'match.files()' returns 'self._files'
          - 'match.exact(f)' examines 'f in self._fmap',
          - 'self._fmap' of match is 'set(self._files)'
      
      then, 'explicitonly' wants to suppress warning messges, if it is true
      (= 'cmdutil.forget()' is invoked from 'subrepo.forget()').
      
      so, current code should be fixed as:
      
          if not explicitonly:
              for f in match.files():
                 ....
      f11eee00c652
  13. Feb 04, 2012
    • Jim Hague's avatar
      tests: fix command line overflow on ksh · f680ed10e2c4
      Jim Hague authored
      "<command> `hg manifest`" overflows the puny 1024 byte command line length
      limit on AIX default shell ksh. Replace with "hg manifest | xargs <command>".
      f680ed10e2c4
  14. Feb 05, 2012
  15. Feb 03, 2012
  16. Feb 01, 2012
Loading