Wed, 10 Dec 2014 23:46:47 -0500 tests: fix a typo in test-walkrepos.py
Enrique A. Tobis <enrique@tobis.com.ar> [Wed, 10 Dec 2014 23:46:47 -0500] rev 23532
tests: fix a typo in test-walkrepos.py
Wed, 03 Dec 2014 13:50:28 -0800 merge: extract _resolvetrivial() function
Martin von Zweigbergk <martinvonz@google.com> [Wed, 03 Dec 2014 13:50:28 -0800] rev 23531
merge: extract _resolvetrivial() function 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.
Tue, 09 Dec 2014 22:10:51 -0800 largefiles: start by finding files of interest
Martin von Zweigbergk <martinvonz@google.com> [Tue, 09 Dec 2014 22:10:51 -0800] rev 23530
largefiles: start by finding files of interest 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'.
Tue, 09 Dec 2014 22:03:53 -0800 largefiles: rewrite merge code using dictionary with entry per file
Martin von Zweigbergk <martinvonz@google.com> [Tue, 09 Dec 2014 22:03:53 -0800] rev 23529
largefiles: rewrite merge code using dictionary with entry per file 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')],
Tue, 09 Dec 2014 09:53:26 -0800 largefiles: put same 'action' object back in 'newglist'
Martin von Zweigbergk <martinvonz@google.com> [Tue, 09 Dec 2014 09:53:26 -0800] rev 23528
largefiles: put same 'action' object back in 'newglist' The items we put in 'newglist' are always the same as what we found in actions['g'], so let's just put the same item into the list instead of creating a new one.
Mon, 08 Dec 2014 15:20:42 -0800 largefiles: don't unnecessarily sort merge action lists
Martin von Zweigbergk <martinvonz@google.com> [Mon, 08 Dec 2014 15:20:42 -0800] rev 23527
largefiles: don't unnecessarily sort merge action lists 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().
Tue, 09 Dec 2014 16:49:55 -0800 merge: don't treat 'diverge' and 'renamedelete' like actions
Martin von Zweigbergk <martinvonz@google.com> [Tue, 09 Dec 2014 16:49:55 -0800] rev 23526
merge: don't treat 'diverge' and 'renamedelete' like actions See earlier patch for motivation.
Tue, 09 Dec 2014 14:18:31 -0800 merge: move dr/rd warning messages out of applyupdates()
Martin von Zweigbergk <martinvonz@google.com> [Tue, 09 Dec 2014 14:18:31 -0800] rev 23525
merge: move dr/rd warning messages out of applyupdates() 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.
(0) -10000 -3000 -1000 -300 -100 -30 -10 -8 +8 +10 +30 +100 +300 +1000 +3000 +10000 tip