Skip to content
Snippets Groups Projects
  1. Dec 13, 2014
  2. Dec 12, 2014
  3. Nov 14, 2014
    • Martin von Zweigbergk's avatar
      merge: perform case-collision checking on final set of actions · 7cc0fb00
      Martin von Zweigbergk authored
      When there are multiple common ancestors, we should check for case
      collisions only on the resulting actions after bid merge has run. To
      do this, move the code until after bid merge.
      
      Move it past _resolvetrivial() too, since that might update
      actions. If the remote changed a file and then reverted the change,
      while the local side deleted the file and created a new file with a
      name that case-folds like the old file, we should fail before this
      patch but not after.
      
      Although the changes to the actions caused by _forgetremoved() should
      have no effect on case collisions, move it after that, too, so the
      next person reading the code won't have to think about it.
      
      Moving it past these blocks of code takes it to the end of
      calculateupdates(), so let's even move it outside of the method, so we
      also check collisions in actions produced by extensions overriding the
      method.
      7cc0fb00
  4. Apr 17, 2014
  5. Dec 13, 2014
  6. Dec 12, 2014
    • Martin von Zweigbergk's avatar
      merge: move cd/dc prompts after largefiles prompts · 495bc1b6
      Martin von Zweigbergk authored
      By moving the cd/dc prompts out of calculateupdates(), we let
      largefiles' overridecalculateupdates() so the unresolved values
      (i.e. 'cd' or 'dc' rather than 'g', 'r', 'a' and missing). This allows
      overridecalculateupdates() to ask the user whether to keep the normal
      file or the largefile before the user gets the cd/dc prompt. Whichever
      answer the user gives, we make overridecalculateupdates() replace 'cd'
      or 'dc' action, saving the user one annoying (and less clear)
      question.
      495bc1b6
  7. Dec 01, 2014
    • Matt Harbison's avatar
      addremove: automatically process a subrepository's subrepos · f274d27f
      Matt Harbison authored
      Since addremove on the top of a directory tree will recursively handle sub
      directories, it should be the same with deep subrepos, once the user has
      explicitly asked to process a subrepo.  This really only has an effect when a
      path that is a subrepo (or is in a subrepo) is given, since -S causes all
      subrepos to be processed already.  An addremove without a path that crosses into
      a subrepo, will still not enter any subrepos, per backward compatibility rules.
      f274d27f
  8. Nov 10, 2014
  9. Nov 25, 2014
  10. Nov 26, 2014
    • Matt Harbison's avatar
      subrepo: store the ui object in the base class · fcbc66b5
      Matt Harbison authored
      This will be used in the next patch to print a warning from the base class.  It
      seems better than having to explicitly pass it to a new method, since a lot of
      existing methods also require it.
      fcbc66b5
    • Matt Harbison's avatar
      commit: abort if --addremove is specified, but fails · 72c23fa4
      Matt Harbison authored
      This will be required when subrepo support is added, in order to ensure
      consistent commits when a subrepo flavor doesn't support addremove.
      72c23fa4
    • Matt Harbison's avatar
      addremove: warn when addremove fails to operate on a named path · 83bbedc1
      Matt Harbison authored
      It looks like a bad path is the only mode of failure for addremove.  This
      warning is probably useful for the standalone command, but more important for
      'commit -A'.  That command doesn't currently abort if the addremove fails, but
      it will be made to do so prior to adding subrepo support, since not all subrepos
      will support addremove.  We could just abort here, but it looks like addremove
      has always silently ignored bad paths, except for the exit code.
      83bbedc1
  11. Nov 10, 2014
  12. Dec 11, 2014
  13. Dec 03, 2014
    • Martin von Zweigbergk's avatar
      merge: extract _resolvetrivial() function · 416c1331
      Martin von Zweigbergk authored
      We would eventually like to move the resolution of modify/delete and
      delete/modify conflicts to the resolve phase. However, we don't want
      to move the checks for identical content that were added in
      902554884335 (merge: before cd/dc prompt, check that changed side
      really changed, 2014-12-01). Let's instead move these out to a new
      _resolvetrivial() function that processes the actions from
      manifestmerge() and replaces any false cd/dc conflicts. The function
      will also provide a natural place for us to later add code for
      resolving false 'm' conflicts.
      416c1331
  14. Dec 10, 2014
    • Martin von Zweigbergk's avatar
      largefiles: start by finding files of interest · 42ae1b1f
      Martin von Zweigbergk authored
      Instead of iterating over 'g' action, first find the set of all files
      that are largefiles in p1. Then iterate over these files. This
      prepares for considering actions other than 'g'.
      42ae1b1f
    • Martin von Zweigbergk's avatar
      largefiles: rewrite merge code using dictionary with entry per file · 38e55e55
      Martin von Zweigbergk authored
      In overridecalculateupdates(), we currently only deal with conflicts
      that result in a 'g' action for either the largefile or a standin. We
      will soon want to deal cases with 'cd' and 'dc' actions here. It will
      be easier to reason about such cases if we rewrite it using a dict
      from filename to action.
      
      A side-effect of this change is that the output can only have one
      action per file (which should be a good change). Before this change,
      when one of the tests in test-issue3084 received this input (the 'a'
      in the input was a result of 'cd' conflict resolved in favor of the
      modified file):
      
        'g': [('.hglf/f', ('',), 'remote created')],
        'a': [('f', None, 'prompt keep')],
      
      and the user chose to keep the local largefile, it produced this
      output:
      
      
        'g': [('.hglf/f', ('',), 'remote created')],
        'r': [('f', None, 'replaced by standin')],
        'a': [('f', None, 'prompt keep')],
      
      Although 'a' actions are processed after 'r' actions by
      recordupdates(), it still worked because 'a' actions have no effect on
      merges (only on updates). After this change, the output is:
      
        'g': [('.hglf/f', ('',), 'remote created')],
        'r': [('f', None, 'replaced by standin')],
      
      Similarly, there are several tests in test-largefiles-update that get
      inputs like:
      
        'a': [('.hglf/large2', None, 'prompt keep')],
        'g': [('large2', ('',), 'remote created')],
      
      and when the user chooses to keep the local largefile, they produce
      this output:
      
        'a': [('.hglf/large2', None, 'prompt keep'),
              ('.hglf/large2', None, 'keep standin')],
        'lfmr': [('large2', None, 'forget non-standin largefile')],
      
      In this case, it was not a merge but an update, so the 'a' action does
      have an effect. However, since dirstate.add() is idempotent, it still
      has no obserable effect.
      
      After this change, the output is:
      
        'a': [('.hglf/large2', None, 'keep standin')],
        'lfmr': [('large2', None, 'forget non-standin largefile')],
      38e55e55
  15. Dec 09, 2014
  16. Dec 08, 2014
    • Martin von Zweigbergk's avatar
      largefiles: don't unnecessarily sort merge action lists · e61de555
      Martin von Zweigbergk authored
      The action lists returned from calculateupdates() (in merge.py) are
      not required to be sorted. In fact, since they result from iteration
      over the unordered manifest, they are unlikely to be sorted. Moreover,
      some of the lists are appended to after they are returned from
      manifestmerge(). The lists are instead sorted in
      applyupdates(). Therefore, let's not sort the lists generated in
      largefiles' overridecalculateupdates().
      e61de555
  17. Dec 10, 2014
  18. Dec 09, 2014
    • Martin von Zweigbergk's avatar
      merge: move dr/rd warning messages out of applyupdates() · 5126d771
      Martin von Zweigbergk authored
      As preparation for making 'dr' and 'rd' actions no longer actions,
      move the reporting from applyupdates() to its caller update(). This
      way we won't have to pass additonal arguments to applyupdates() when
      they are no longer actions. Also, the warnings are equally unrelated
      to applyupdates() as they are to recordupdates(), as they don't result
      in any changes to either the working copy or the dirstate.
      
      See earlier patch for additional motivation.
      5126d771
  19. Dec 06, 2014
    • Martin von Zweigbergk's avatar
      merge: don't report progress for dr/rd actions · a1a7c94d
      Martin von Zweigbergk authored
      It is easier to reason about certain algorithms in terms of a
      file->action mapping than the current action->list-of-files. Bid merge
      is already written this way (but with a list of actions per file), and
      largefiles' overridecalculateupdates() will also benefit. However,
      that requires us to have at most one action per file. That requirement
      is currently violated by 'dr' (divergent rename) and 'rd' (rename and
      delete) actions, which can exist for the same file as some other
      action.
      
      These actions are only used for displaying warnings to the user; they
      don't change anything in the working copy or the dirstate. In this
      way, they are similar to the 'k' (keep) action. However, they are even
      less action-like than 'k' is: 'k' at least describes what to do with
      the file ("do nothing"), while 'dr' and 'rd' or only annotations for
      files for which there may exist other, "real" actions.
      
      As a first step towards separating these acitons out, stop including
      them in the progress output, just like we already exclude the 'k'
      action.
      a1a7c94d
  20. Dec 10, 2014
  21. Oct 11, 2012
    • kiilerix's avatar
      rebase: show a note for updated mq patches · de143427
      kiilerix authored
      It deserves more than a debug message. Show a note like:
      
        updating mq patch p0.patch to 5:9ecc820b1737
      
      The message could also refer to "qrefresh" instead. Same same.
      de143427
  22. Dec 10, 2014
  23. Dec 09, 2014
  24. Dec 07, 2014
  25. Dec 09, 2014
  26. Dec 04, 2014
  27. Dec 05, 2014
    • Pierre-Yves David's avatar
      fncache: document the fact fncache is outdate at hook run time · acc73273
      Pierre-Yves David authored
      Using 'addfinalize' to generate 'fncache' means that no pending version of the
      file will be generated for the hooks. We would have to use the
      'addfilegenerator' method to get such result. However the 'fncachevfs' (who
      decide that a write is necessary) have no access to the transaction to register
      such file generation at add time. Having the transaction accessible to the 'vfs'
      is too much trouble for no benefit. This outdated 'fncache' file at hook time is
      not expected to be an issue.
      
      The previous move from 'onclose' to 'addfinalize' had no impact on this timing.
      I'm documenting it now because I looked at it.
      acc73273
  28. Dec 04, 2014
  29. Dec 09, 2014
Loading