Mon, 05 Oct 2015 10:43:16 -0600 notify: fix fromauthor setting for 'incoming' hook type (issue4194) stable
Bruce Cran <bruce.cran@gmail.com> [Mon, 05 Oct 2015 10:43:16 -0600] rev 26503
notify: fix fromauthor setting for 'incoming' hook type (issue4194) Set the author field in notification emails for the 'incoming' hook type in addition to 'changegroup' and 'outgoing' types.
Mon, 05 Oct 2015 12:37:26 -0400 templater: protect word() from crashing on out of range negative value stable
Matt Harbison <matt_harbison@yahoo.com> [Mon, 05 Oct 2015 12:37:26 -0400] rev 26502
templater: protect word() from crashing on out of range negative value The function isn't documented to work with negative values at all, but it does, which can be useful. However, the range check didn't account for this.
Fri, 02 Oct 2015 13:00:47 -0700 commands: add a new debug command to print merge state
Siddharth Agarwal <sid0@fb.com> [Fri, 02 Oct 2015 13:00:47 -0700] rev 26501
commands: add a new debug command to print merge state We're going to be extending the merge state very soon, and this will give us a way to test all that.
Wed, 30 Sep 2015 21:22:31 -0700 merge.mergestate: factor out code to validate v1/v2 records
Siddharth Agarwal <sid0@fb.com> [Wed, 30 Sep 2015 21:22:31 -0700] rev 26500
merge.mergestate: factor out code to validate v1/v2 records We're going to need this in another place in upcoming patches.
Tue, 06 Oct 2015 13:19:05 -0700 localrepo: prevent wlock from being inherited when a transaction is running
Siddharth Agarwal <sid0@fb.com> [Tue, 06 Oct 2015 13:19:05 -0700] rev 26499
localrepo: prevent wlock from being inherited when a transaction is running Review feedback from Pierre-Yves David. A separate line of work is working to ensure that dirstate writes are written to a separate 'pending' file while a transaction is active. Lock inheritance currently conflicts with that, so dodge the issue by simply preventing inheritance while a transaction is running. Custom merge drivers aren't going to run inside a transaction, so this doesn't affect that.
Tue, 06 Oct 2015 13:13:31 -0700 lock: add a way to prevent locks from being inherited
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.)
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.
Thu, 24 Sep 2015 13:58:18 -0400 test-help: verify that extension keywords appear in help templates
timeless@mozdev.org [Thu, 24 Sep 2015 13:58:18 -0400] rev 26487
test-help: verify that extension keywords appear in help templates fixed by a2291c9c85a1
Mon, 24 Aug 2015 23:30:17 -0400 templatekw: add {changes}, {distance} and {tag} to the {latesttag} keyword
Matt Harbison <matt_harbison@yahoo.com> [Mon, 24 Aug 2015 23:30:17 -0400] rev 26486
templatekw: add {changes}, {distance} and {tag} to the {latesttag} keyword
Sun, 23 Aug 2015 23:44:58 -0400 templater: introduce {latesttag()} function to match a pattern (issue4184)
Matt Harbison <matt_harbison@yahoo.com> [Sun, 23 Aug 2015 23:44:58 -0400] rev 26485
templater: introduce {latesttag()} function to match a pattern (issue4184) This allows the latest class of tag to be found, such as a release candidate or final build, instead of just the absolute latest. It doesn't appear that the existing keyword can be given an optional argument. There is a keyword, function and filter for 'date', so it doesn't seem harmful to introduce a new function with the same name as an existing keyword. Most functions are pretty Mercurial agnostic, but there is {revset()} as precedent. Even though templatekw.getlatesttags() returns a single tuple, one entry of which is a list, it is simplest to present this as a list of tags instead of a single item, with each tag having a distance and change count attribute. It is also closer to how {latesttag} returns a list of tags, and how this function works when not given a '%' operator.
Mon, 24 Aug 2015 23:07:00 -0400 templatekw: introduce showlatesttags() to handle {latesttag} keywords
Matt Harbison <matt_harbison@yahoo.com> [Mon, 24 Aug 2015 23:07:00 -0400] rev 26484
templatekw: introduce showlatesttags() to handle {latesttag} keywords The keywords {changes}, {distance} and {tag} will be available on a future template method that will allow pattern matching against tag names. For consistency, these should be available on the existing {latesttag} keyword as well. I debated whether or not to add {tag} instead of just continuing with the existing {latesttag}. But it seems clearer not to have the same name for two distinct things (a list in the LHS of %, and an individual tag value on the right). The value of latesttags[0] is the date of commit for the cset to which the tag is applied (i.e. not the date the tag was applied), and therefore isn't made visible because it doesn't seem interesting. It appears that this is merely an internal implementation detail for sorting csets in a stable manner when there are different branches.
Mon, 05 Oct 2015 21:11:50 -0400 templatekw: factor out the changessincetag calculation to a private method
Matt Harbison <matt_harbison@yahoo.com> [Mon, 05 Oct 2015 21:11:50 -0400] rev 26483
templatekw: factor out the changessincetag calculation to a private method This will be reused in the next patch.
Sun, 23 Aug 2015 23:22:55 -0400 templatekw: allow getlatesttags() to match a specific tag pattern
Matt Harbison <matt_harbison@yahoo.com> [Sun, 23 Aug 2015 23:22:55 -0400] rev 26482
templatekw: allow getlatesttags() to match a specific tag pattern This will allow the latest class of tag to be found, such as a release candidate or final build, instead of just the absolute latest. It will be exposed in a future patch. It's unfortunate that the original 'latesttags' cache can't be used to determine the proper values, but it isn't fully populated for the entire repo. For example, the {latesttagdistance} keyword on the Mecurial repo builds the cache up back to the revision for 1.4. If the pattern was 're:^0\.\d$', that wouldn't be in the cache. Maybe this can be optimized some other way, but for now, this is the simpliest implementation.
Sat, 22 Aug 2015 22:52:18 -0400 util: extract stringmatcher() from revset
Matt Harbison <matt_harbison@yahoo.com> [Sat, 22 Aug 2015 22:52:18 -0400] rev 26481
util: extract stringmatcher() from revset This is used to match against tags, bookmarks, etc in revsets. It will be used in a future patch to do the same tag matching in templater.
Mon, 05 Oct 2015 17:36:32 -0700 util.chunkbuffer: avoid extra mutations when reading partial chunks
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 05 Oct 2015 17:36:32 -0700] rev 26480
util.chunkbuffer: avoid extra mutations when reading partial chunks Previously, a read(N) where N was less than the length of the first available chunk would mutate the deque instance twice and allocate a new str from the slice of the existing chunk. Profiling drawed my attention to these as a potential hot spot during changegroup reading. This patch makes the code more complicated in order to avoid the aforementioned 3 operations. On a pre-generated mozilla-central gzip bundle, this series has the following impact on `hg unbundle` performance on my MacBook Pro: before: 358.21 real 317.69 user 38.49 sys after: 301.57 real 262.69 user 37.11 sys delta: -56.64 real -55.00 user -1.38 sys
Mon, 05 Oct 2015 16:34:47 -0700 util.chunkbuffer: refactor chunk handling logic
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 05 Oct 2015 16:34:47 -0700] rev 26479
util.chunkbuffer: refactor chunk handling logic This will make the next patch easier to read. It provides no benefit on its own.
Mon, 05 Oct 2015 16:28:12 -0700 util.chunkbuffer: special case reading everything
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 05 Oct 2015 16:28:12 -0700] rev 26478
util.chunkbuffer: special case reading everything The new code results in simpler logic within the while loop. It is also faster since we avoid performing operations on the queue and buf collections. However, there shouldn't be any super hot loops for this since the whole point of chunkbuffer is to avoid reading large amounts of data at once. This does, however, make it easier to optimize chunkbuffer in a subsequent patch.
Mon, 05 Oct 2015 07:13:35 +0200 revert: add reference to backout
Mathias De Maré <mathias.demare@gmail.com> [Mon, 05 Oct 2015 07:13:35 +0200] rev 26477
revert: add reference to backout
Mon, 05 Oct 2015 07:11:48 +0200 backout: add reference to revert
Mathias De Maré <mathias.demare@gmail.com> [Mon, 05 Oct 2015 07:11:48 +0200] rev 26476
backout: add reference to revert
Fri, 25 Sep 2015 12:39:23 -0700 localrepo: allow wlock to be inherited
Siddharth Agarwal <sid0@fb.com> [Fri, 25 Sep 2015 12:39:23 -0700] rev 26475
localrepo: allow wlock to be inherited This is part of a series that will allow locks to be inherited by subprocesses in limited circumstances. When allowed, the parent process will pass down requisite information to the child process by way of this environment variable.
Sun, 04 Oct 2015 20:04:44 -0700 lock.release: don't call postrelease functions for inherited locks
Siddharth Agarwal <sid0@fb.com> [Sun, 04 Oct 2015 20:04:44 -0700] rev 26474
lock.release: don't call postrelease functions for inherited locks Review feedback from Pierre-Yves David. The postrelease functions typically assume the lock is not held at all.
Sun, 04 Oct 2015 20:02:50 -0700 lock: turn prepinherit/reacquire into a single context manager
Siddharth Agarwal <sid0@fb.com> [Sun, 04 Oct 2015 20:02:50 -0700] rev 26473
lock: turn prepinherit/reacquire into a single context manager Review feedback from Pierre-Yves David. This makes the overall code cleaner and less error-prone, and makes a previously explicitly checked error state impossible.
Sun, 04 Oct 2015 19:28:43 -0700 localrepo: add a note about parentenvvar
Siddharth Agarwal <sid0@fb.com> [Sun, 04 Oct 2015 19:28:43 -0700] rev 26472
localrepo: add a note about parentenvvar Review feedback from Pierre-Yves David.
(0) -10000 -3000 -1000 -300 -100 -50 -32 +32 +50 +100 +300 +1000 +3000 +10000 tip