Mon, 08 Aug 2016 18:05:10 +0200 journal: take wlock for writting the 'shared' file
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Mon, 08 Aug 2016 18:05:10 +0200] rev 29768
journal: take wlock for writting the 'shared' file As we did for the shared extension itself, we add some locking around the write of the 'shared' file.
Sun, 07 Aug 2016 17:15:19 +0200 debugbuilddag: take wlock to cover '.hg/localtags'
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Sun, 07 Aug 2016 17:15:19 +0200] rev 29767
debugbuilddag: take wlock to cover '.hg/localtags' This debug command can write local tags. local tags are in the .hg directory and should be covered by the 'wlock'. This is now covered.
Mon, 08 Aug 2016 17:33:45 +0200 fakemergerecord: take wlock to write the merge state
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Mon, 08 Aug 2016 17:33:45 +0200] rev 29766
fakemergerecord: take wlock to write the merge state The merge state is supposed to be covered by the wlock. We fix the test extensions to comply to that.
Sun, 07 Aug 2016 17:10:47 +0200 shared: take wlock for writting the 'shared' file
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Sun, 07 Aug 2016 17:10:47 +0200] rev 29765
shared: take wlock for writting the 'shared' file I do not see a reason why this should not be covered by the wlock.
Sun, 07 Aug 2016 17:00:45 +0200 mq: take wlock when 'qqueue' is doing write operations
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Sun, 07 Aug 2016 17:00:45 +0200] rev 29764
mq: take wlock when 'qqueue' is doing write operations Apparently when this command was added, the locking was forgotten. No code changes beside the indentation from the locking context.
Tue, 09 Aug 2016 02:28:34 +0900 py3: make check-py3-compat.py use correct module name at loading pure modules
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Tue, 09 Aug 2016 02:28:34 +0900] rev 29763
py3: make check-py3-compat.py use correct module name at loading pure modules Before this patch, check-py3-compat.py implies unintentional ".pure" sub-package name at loading pure modules, because module name is composed by just replacing "/" in the path to actual ".py" file by ".". This makes pure modules belong to "mercurial.pure" package, and prevents them from importing a module belonging to "mercurial" package relatively by "from . import foo" or so. This is reason why pure modules fail to import another module relatively only at examination by check-py3-compat.py.
(0) -10000 -3000 -1000 -300 -100 -30 -10 -6 +6 +10 +30 +100 +300 +1000 +3000 +10000 tip