Siddharth Agarwal <sid0@fb.com> [Tue, 06 Oct 2015 13:13:31 -0700] rev 26498
lock: add a way to prevent locks from being inherited
We want to prevent locks from being inherited sometimes (e.g. when there's a
currently running transaction, which will break a lot of assumptions we're
making in here.)
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.
timeless@mozdev.org [Tue, 06 Oct 2015 15:07:00 -0400] rev 26496
rebase: enable histedit for useful help with it
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.
timeless@mozdev.org [Tue, 06 Oct 2015 15:05:40 -0400] rev 26494
rebase: factor out histedit help command
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.
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.
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.
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.
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.