Thu, 16 Apr 2015 10:12:44 -0400 tags: don't read .hgtags fnodes from tags cache files
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 16 Apr 2015 10:12:44 -0400] rev 24759
tags: don't read .hgtags fnodes from tags cache files Now that we have a standalone and shared cache for .hgtags fnodes, the .hgtags fnodes stored in the tags cache files are redundant. Upcoming patches will change the format of the tags cache files to remove this data and to improve the validation. To prepare for this, we change the tags reading code to ignore all but the tip .hgtags fnodes entries in existing tags cache files. All fnodes lookups now go through our new shared cache, which is why test output changed. Format of tags cache files has not yet changed.
Mon, 13 Apr 2015 14:54:02 -0400 rebase: restore bookmark state on abort
Tony Tung <tonytung@fb.com> [Mon, 13 Apr 2015 14:54:02 -0400] rev 24758
rebase: restore bookmark state on abort The bookmark state was already being preserved, but it wasn't being properly restored.
Sat, 04 Apr 2015 02:37:43 -0700 histedit: store backup file before histedit
Durham Goode <durham@fb.com> [Sat, 04 Apr 2015 02:37:43 -0700] rev 24757
histedit: store backup file before histedit It's possible for the user to delete some of the commits they started with during a histedit, and aborting the histedit doesn't bring them back. Let's store a backup bundle so we can always recover the stack of commits from before they began.
Mon, 13 Apr 2015 08:23:57 -0700 histedit: replace pickle with custom serialization
Durham Goode <durham@fb.com> [Mon, 13 Apr 2015 08:23:57 -0700] rev 24756
histedit: replace pickle with custom serialization Pickle is undesirable, so let's serialize it ourselves. We keep the ability to parse existing pickle blobs for now.
Wed, 15 Apr 2015 01:18:09 -0400 devel-warn: add a prefix to all messages ("devel-warn: ")
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 15 Apr 2015 01:18:09 -0400] rev 24755
devel-warn: add a prefix to all messages ("devel-warn: ") We want to make the origin and importance of the message clear to developers.
Wed, 15 Apr 2015 10:36:21 -0400 push: acquire local 'wlock' if "pushback" is expected (BC) (issue4596)
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 15 Apr 2015 10:36:21 -0400] rev 24754
push: acquire local 'wlock' if "pushback" is expected (BC) (issue4596) If the client allows "pushback", the bundle2 served back by the server may contains parts that will write to the repository. Such parts may require the 'wlock' (eg: bookmark) so we acquire it in advance to make sure it got acquired before the 'lock'.
Thu, 16 Apr 2015 22:33:53 +0900 annotate: always prepare ancestry context of base fctx (issue4600) stable
Yuya Nishihara <yuya@tcha.org> [Thu, 16 Apr 2015 22:33:53 +0900] rev 24753
annotate: always prepare ancestry context of base fctx (issue4600) This patch extends the workaround introduced by dd01834a696f. Even if the base fctx is the same as intorrev, _ancestrycontext must be built for faster _changeid lookup. repo: https://hg.mozilla.org/releases/mozilla-beta command: hg annotate -r 4954faa47dd0 gfx/thebes/gfxWindowsPlatform.cpp before: 52.450 sec after: 1.820 sec
Wed, 15 Apr 2015 01:16:40 -0400 unbundle: acquire 'wlock' when processing bundle2 (BC) (issue4596)
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 15 Apr 2015 01:16:40 -0400] rev 24752
unbundle: acquire 'wlock' when processing bundle2 (BC) (issue4596) A bundle2 may contain bookmark updates (or other extension content) that requires the 'wlock' to be written. As 'wlock' must be acquired before 'lock', we must stay on the side of caution and use both in all case to ensure their ordering.
Sun, 12 Apr 2015 09:46:03 -0400 run-test: enable the devel warning during tests
Pierre-Yves David <pierre-yves.david@fb.com> [Sun, 12 Apr 2015 09:46:03 -0400] rev 24751
run-test: enable the devel warning during tests This should help us to catch new locking order issues as soon as possible. There are two harmless test updates (from the config change). Moreover, some bundle2 tests are displaying warning for a legitimate reason. The use of pushkey during the unbundle process may requires the 'wlock' after 'lock' (around the whole unbundle process was taken). This is non-trivial to fix, so I better have the check on, with the warning in the test than the check off. See issue4596 for details.
Sun, 12 Apr 2015 15:37:59 -0400 wlock: do not warn for non-wait locking
Pierre-Yves David <pierre-yves.david@fb.com> [Sun, 12 Apr 2015 15:37:59 -0400] rev 24750
wlock: do not warn for non-wait locking We are warning about lock acquired in the wrong order because this can create dead-lock situation. But non-wait acquisition will not block and therefore not create a dead-lock. So we do not need to wait in such case.
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip