Tue, 06 Oct 2015 15:55:50 -0700 test-fncache: use args/kwargs for lock wrapper
Siddharth Agarwal <sid0@fb.com> [Tue, 06 Oct 2015 15:55:50 -0700] rev 26497
test-fncache: use args/kwargs for lock wrapper This is annoying to keep up to date, and also just plain unnecessary.
Tue, 06 Oct 2015 15:07:00 -0400 rebase: enable histedit for useful help with it
timeless@mozdev.org [Tue, 06 Oct 2015 15:07:00 -0400] rev 26496
rebase: enable histedit for useful help with it
Tue, 06 Oct 2015 15:01:25 -0400 rebase: suggest help -e histedit
timeless@mozdev.org [Tue, 06 Oct 2015 15:01:25 -0400] rev 26495
rebase: suggest help -e histedit Users unfamiliar with an extension should be reading the documentation for the feature, not the command.
Tue, 06 Oct 2015 15:05:40 -0400 rebase: factor out histedit help command
timeless@mozdev.org [Tue, 06 Oct 2015 15:05:40 -0400] rev 26494
rebase: factor out histedit help command
Sun, 04 Oct 2015 22:35:36 +0900 util: use tuple accessor to get accurate st_mtime value (issue4836)
Yuya Nishihara <yuya@tcha.org> [Sun, 04 Oct 2015 22:35:36 +0900] rev 26493
util: use tuple accessor to get accurate st_mtime value (issue4836) Because st.st_mtime is computed as 'sec + 1e-9 * nsec' and double is too narrow to represent nanoseconds, int(st.st_mtime) can be 'sec + 1'. Therefore, that value could be different from the one got by osutils.listdir(). This patch fixes the problem by accessing to raw st_mtime by tuple index. It catches TypeError to fall back to st.st_mtime because our osutil.stat does not support tuple index. In dirstate.normal(), 'st' is always a Python stat, but in dirstate.status(), it can be either a Python stat or an osutil.stat. Thanks to vgatien-baron@janestreet.com for finding the root cause of this subtle problem.
Sun, 04 Oct 2015 22:25:29 +0900 util: extract stub function to get mtime with second accuracy
Yuya Nishihara <yuya@tcha.org> [Sun, 04 Oct 2015 22:25:29 +0900] rev 26492
util: extract stub function to get mtime with second accuracy This function is trivial but will need a long comment why it can't use st.st_mtime. See the next patch for details.
Mon, 05 Oct 2015 14:37:59 -0700 scmutil: add a way for a repo's wlock to be inherited by a subprocess
Siddharth Agarwal <sid0@fb.com> [Mon, 05 Oct 2015 14:37:59 -0700] rev 26491
scmutil: add a way for a repo's wlock to be inherited by a subprocess This is part of a series that will allow locks to be inherited by subprocesses in limited circumstances. In the future, we'll call this for custom merge drivers.
Mon, 05 Oct 2015 14:34:52 -0700 scmutil: add a way for a subprocess to be run with an inheritable lock
Siddharth Agarwal <sid0@fb.com> [Mon, 05 Oct 2015 14:34:52 -0700] rev 26490
scmutil: add a way for a subprocess to be run with an inheritable lock This is part of a series that will allow locks to be inherited by subprocesses in limited circumstances. In an upcoming patch, we'll add an API for the wlock to be inherited.
Mon, 05 Oct 2015 14:27:37 -0700 localrepo: add a way to get the current wlock if it's held
Siddharth Agarwal <sid0@fb.com> [Mon, 05 Oct 2015 14:27:37 -0700] rev 26489
localrepo: add a way to get the current wlock if it's held This will be useful to pass around a reference to the lock to some functions we're going to add to scmutil. We don't want those functions to live in localrepo to avoid bloat.
Mon, 05 Oct 2015 14:26:53 -0700 localrepo: add a way to get the current lock if it's held
Siddharth Agarwal <sid0@fb.com> [Mon, 05 Oct 2015 14:26:53 -0700] rev 26488
localrepo: add a way to get the current lock if it's held We'll use this in upcoming patches to return a reference to the wlock if it's held.
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip