Wed, 19 Nov 2014 11:51:31 -0800 merge: collect checking for unknown files at end of manifestmerge()
Martin von Zweigbergk <martinvonz@google.com> [Wed, 19 Nov 2014 11:51:31 -0800] rev 23651
merge: collect checking for unknown files at end of manifestmerge() The 'c' and 'dc' actions include creating a file on disk and we need to check that no conflicting file exists unless force=True. Move two of the calls to _checkunknownfile() to a single place at the end of manifestmerge(). This removes some of the reading of filelogs from the heart of manifestmerge() and collects it in one place close to where its output (entries in the 'aborts' list) is used. Note that this removes the unnecessary call to _checkunknownfile() when force=True in one of the code paths.
Wed, 19 Nov 2014 11:48:30 -0800 merge: introduce 'c' action like 'g', but with additional safety
Martin von Zweigbergk <martinvonz@google.com> [Wed, 19 Nov 2014 11:48:30 -0800] rev 23650
merge: introduce 'c' action like 'g', but with additional safety _checkunknownfile() reads the filelog of the remote side's file. For narrow clones, the filelog will not exist for all files and we need a way to avoid reading them. While it would be easier for the narrow extension to just override _checkunknownfile() and make it ignore files outside the narrow clone, it seems cleaner to have manifestmerge() not care about filelogs (considering its name). In order to move the calls to _checkunknownfile() out, we need to be able to tell in which cases we should check for unknown files. Let's start by introducing a new action distinct from 'g' for this purpose. Specifically, the new action will be just like 'g' except that it will check that for conflicting unknown files first. For now, just add the new action type and convert it to 'g'.
Wed, 19 Nov 2014 11:44:00 -0800 merge: structure 'remote created' code to match table
Martin von Zweigbergk <martinvonz@google.com> [Wed, 19 Nov 2014 11:44:00 -0800] rev 23649
merge: structure 'remote created' code to match table This does duplicate the call to _checkunknownfile(), but it will simplify future patches.
Mon, 22 Dec 2014 15:48:39 -0800 pushkey: run hook after the lock release
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 22 Dec 2014 15:48:39 -0800] rev 23648
pushkey: run hook after the lock release The pushkey operation used to be in its own wireprotocol command and (in practice) always be lock free when running the hook. With bundle2, it happen in a greater scheme and a hook running locking command would get stuck. We now run such hooks after the lock release as similar hook do. Bundle2 test are altered to ensure we are lockfree at hook running time.
(0) -10000 -3000 -1000 -300 -100 -30 -10 -4 +4 +10 +30 +100 +300 +1000 +3000 +10000 tip