Sun, 19 Mar 2017 01:14:19 -0400 revsetlang: move quoting function to not be a closure
Augie Fackler <augie@google.com> [Sun, 19 Mar 2017 01:14:19 -0400] rev 31604
revsetlang: move quoting function to not be a closure I'm about to change the implementation here and I'd like to add some doctests, which means this needs to not be hidden inside another function.
Thu, 23 Mar 2017 10:33:20 -0400 revsetlang: portably bytestring-ify another pair of int() calls
Augie Fackler <augie@google.com> [Thu, 23 Mar 2017 10:33:20 -0400] rev 31603
revsetlang: portably bytestring-ify another pair of int() calls
Thu, 23 Mar 2017 21:23:21 -0700 checkcode: enforce lowercase for extension docstring title
Jun Wu <quark@fb.com> [Thu, 23 Mar 2017 21:23:21 -0700] rev 31602
checkcode: enforce lowercase for extension docstring title This will ensure new extensions are consistent and `hg help -e` has a consistent output. I have to add a new group since the normal "pypats" will be filtered by "pyfilters", which will remove comments and docstrings.
Thu, 23 Mar 2017 21:16:55 -0700 logtoprocess: use lowercase for docstring title
Jun Wu <quark@fb.com> [Thu, 23 Mar 2017 21:16:55 -0700] rev 31601
logtoprocess: use lowercase for docstring title
Thu, 23 Mar 2017 21:16:29 -0700 journal: use lowercase for docstring title
Jun Wu <quark@fb.com> [Thu, 23 Mar 2017 21:16:29 -0700] rev 31600
journal: use lowercase for docstring title See the previous patch for why.
Thu, 23 Mar 2017 21:15:39 -0700 automv: use lowercase for docstring title
Jun Wu <quark@fb.com> [Thu, 23 Mar 2017 21:15:39 -0700] rev 31599
automv: use lowercase for docstring title The first line of docstring is used in `hg help -e`. Use lowercase to be consistent with most extensions.
Thu, 23 Mar 2017 22:31:50 -0700 util: enable hardlink for some BSD-family filesystems
Jun Wu <quark@fb.com> [Thu, 23 Mar 2017 22:31:50 -0700] rev 31598
util: enable hardlink for some BSD-family filesystems Since we can now detect filesystems on FreeBSD and OSX. Add their major filesystems (ufs, zfs for FreeBSD; hfs for OSX) to the hardlink whitelist.
Thu, 23 Mar 2017 22:13:02 -0700 osutil: report fstype for BSD and OSX
Jun Wu <quark@fb.com> [Thu, 23 Mar 2017 22:13:02 -0700] rev 31597
osutil: report fstype for BSD and OSX
Thu, 23 Mar 2017 22:15:36 -0700 setup: use a more strict way to test BSD or OSX's statfs
Jun Wu <quark@fb.com> [Thu, 23 Mar 2017 22:15:36 -0700] rev 31596
setup: use a more strict way to test BSD or OSX's statfs We want to use the `f_fstypename` field to get the filesystem type. Test it directly. The new macro HAVE_BSD_STATFS implys the old HAVE_SYS_MOUNT_H and HAVE_SYS_PARAM_H. So the latter ones are removed.
Thu, 23 Mar 2017 12:03:19 -0700 debugfsinfo: use util.getfstype
Jun Wu <quark@fb.com> [Thu, 23 Mar 2017 12:03:19 -0700] rev 31595
debugfsinfo: use util.getfstype This changes the behavior slightly. It now always prints fstype, regardless of whether osutil.getfstype exists.
Thu, 23 Mar 2017 12:01:18 -0700 util: use util.getfstype
Jun Wu <quark@fb.com> [Thu, 23 Mar 2017 12:01:18 -0700] rev 31594
util: use util.getfstype
Thu, 23 Mar 2017 11:58:45 -0700 util: add a getfstype method
Jun Wu <quark@fb.com> [Thu, 23 Mar 2017 11:58:45 -0700] rev 31593
util: add a getfstype method The util version is a thin wrapper of the osutil version, which is not always available.
Mon, 20 Mar 2017 00:19:33 -0400 pager: fix the invocation of `more` on Windows
Matt Harbison <matt_harbison@yahoo.com> [Mon, 20 Mar 2017 00:19:33 -0400] rev 31592
pager: fix the invocation of `more` on Windows After 9335dc6b2a9c, with 'shell' being (mostly) set to False, invoking `more` no longer worked. Instead, a warning was printed and the pager was disabled. Invoking `more.com` works. Since a user may have configured 'pager.pager=more', do this substitution at the end. Surprisingly, `more` does allow for arguments, so those are preserved. This also allows `more` to work in MSYS. Setting 'shell=False' runs the executable via CreateProcess(), which has rather wonky rules for resolving an executable without an extension [1]. Resolving to *.com is not among them. Since 'shell=True' yields a cryptic error for a bad $PAGER, and a *.exe program will work without specifying the extension, sticking with current 'shell=False' seems like the right thing to do. I don't think there are any other *.com pagers out there, so this one special case seems OK. If somebody wants to do something crazy that requires cmd.exe, I was able to get normal paged output with 'pager.pager="cmd.exe /c more"'. I assume you can replace `more` with *.bat, *.vbs or various other creatures listed in $PATHEXT. [1] https://msdn.microsoft.com/en-us/library/windows/desktop/ms682425(v=vs.85).aspx
Wed, 22 Mar 2017 16:36:53 -0700 help: format ``commands`` heading correctly
Martin von Zweigbergk <martinvonz@google.com> [Wed, 22 Mar 2017 16:36:53 -0700] rev 31591
help: format ``commands`` heading correctly The number of dashes under it needs to match exactly for it to be rendered as a heading. Without this change, the dashes end up on the same line as "commands", and "hg help config.commands" does not work.
Wed, 22 Mar 2017 14:12:58 -0500 convert: fix the handling of empty changlist descriptions in P4
David Soria Parra <davidsp@fb.com> [Wed, 22 Mar 2017 14:12:58 -0500] rev 31590
convert: fix the handling of empty changlist descriptions in P4 Empty changelist descriptions are valid in Perforce. If we encounter one of them we are currently running into an IndexError. In case of empty commit messages set the commit message to **empty changelist description**, which follows Perforce terminology.
Tue, 21 Mar 2017 17:50:44 -0700 status: support commands.status.relative config
Martin von Zweigbergk <martinvonz@google.com> [Tue, 21 Mar 2017 17:50:44 -0700] rev 31589
status: support commands.status.relative config When the config is set to true, status output becomes relative to the working directory. This has bugged me since I started using hg and it turns it is sillily simple to support it (unless I missed something, of course). We could also add a --relative flag, but I would personally always want that on, and I haven't heard any use for having it sometimes on, so this patch only lets you enable it via config.
Tue, 21 Mar 2017 21:26:52 -0700 plain: ignore [commands] config
Martin von Zweigbergk <martinvonz@google.com> [Tue, 21 Mar 2017 21:26:52 -0700] rev 31588
plain: ignore [commands] config We only have commands.{update,rebase}.requiredest so far. We should clearly ignore those two if HGPLAIN is in effect, and it seems like we should ignore any future config that will be added in [commands] since that is about changing the behavior of commands. Thanks to Yuya for suggesting to centralize the code in ui.py. While at it, remove the unnecessary False values passed to ui.configbool() for the aforementioned config options.
Thu, 23 Mar 2017 19:54:59 -0700 changegroup: store old heads as a set stable 4.1.2
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 23 Mar 2017 19:54:59 -0700] rev 31587
changegroup: store old heads as a set Previously, the "oldheads" variable was a list. On a repository at Mozilla with 46,492 heads, profiling revealed that list membership testing was dominating execution time of applying small changegroups. This patch converts the list of old heads to a set. This makes membership testing significantly faster. On the aforementioned repository with 46,492 heads: $ hg unbundle <file with 1 changeset> before: 18.535s wall after: 1.303s Consumers of this variable only check for truthiness (`if oldheads`), length (`len(oldheads)`), and (most importantly) item membership (`h not in oldheads` - which occurs twice). So, the change to a set should be safe and suitable for stable. The practical effect of this change is that changegroup application and related operations (like `hg push`) no longer exhibit an O(n^2) CPU explosion as the number of heads grows.
Tue, 21 Mar 2017 23:30:13 +0100 checkheads: extract obsolete post processing in its own function
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 21 Mar 2017 23:30:13 +0100] rev 31586
checkheads: extract obsolete post processing in its own function The checkheads function is long and complex, extract that logic in a subfunction is win in itself. As the comment in the code says, this postprocessing is currently very basic and either misbehave or fails to detect valid push in many cases. My deeper motive for this extraction is to be make it easier to provide extensive testing of this case and strategy to cover them. Final test and logic will makes it to core once done.
Wed, 22 Mar 2017 11:26:23 -0700 tests: make test-simplekeyvaluefile.py py2.6-compatible
Kostia Balytskyi <ikostia@fb.com> [Wed, 22 Mar 2017 11:26:23 -0700] rev 31585
tests: make test-simplekeyvaluefile.py py2.6-compatible Python 2.6 unittest.TestCase does not have assertRaisesRegexp.
Thu, 23 Mar 2017 20:57:27 +0900 similar: use cheaper hash() function to test exact matches
Yuya Nishihara <yuya@tcha.org> [Thu, 23 Mar 2017 20:57:27 +0900] rev 31584
similar: use cheaper hash() function to test exact matches We just need a hash table {fctx.data(): fctx} which doesn't keep fctx.data() in memory. Let's simply use hash(fctx.data()) to put data out from memory, and manage collided fctx objects by list. This isn't significantly faster than using sha1, but is more correct as we know SHA-1 collision attack is getting practical. Benchmark with 50k added/removed files, on tmpfs: $ hg addremove --dry-run --time -q previous: real 12.420 secs (user 11.120+0.000 sys 1.280+0.000) this patch: real 12.350 secs (user 11.210+0.000 sys 1.140+0.000)
Thu, 23 Mar 2017 20:52:41 +0900 similar: take the first match instead of the last
Yuya Nishihara <yuya@tcha.org> [Thu, 23 Mar 2017 20:52:41 +0900] rev 31583
similar: take the first match instead of the last It seems more natural. This makes the next patch slightly cleaner.
Thu, 23 Mar 2017 21:17:08 +0900 similar: do not look up and create filectx more than once
Yuya Nishihara <yuya@tcha.org> [Thu, 23 Mar 2017 21:17:08 +0900] rev 31582
similar: do not look up and create filectx more than once Benchmark with 50k added/removed files, on tmpfs: $ hg addremove --dry-run --time -q previous: real 16.070 secs (user 14.470+0.000 sys 1.580+0.000) this patch: real 12.420 secs (user 11.120+0.000 sys 1.280+0.000)
Thu, 23 Mar 2017 21:10:45 +0900 similar: use common names for changectx variables
Yuya Nishihara <yuya@tcha.org> [Thu, 23 Mar 2017 21:10:45 +0900] rev 31581
similar: use common names for changectx variables We generally use 'wctx' and 'pctx' for working context and its parent respectively.
Thu, 23 Mar 2017 20:50:33 +0900 similar: get rid of quadratic addedfiles.remove()
Yuya Nishihara <yuya@tcha.org> [Thu, 23 Mar 2017 20:50:33 +0900] rev 31580
similar: get rid of quadratic addedfiles.remove() Instead, build a set of files to be removed and recreate addedfiles only if necessary. Benchmark with 50k added/removed files, on tmpfs: $ hg addremove --dry-run --time -q original: real 16.550 secs (user 15.000+0.000 sys 1.540+0.000) previous: real 16.730 secs (user 15.280+0.000 sys 1.440+0.000) this patch: real 16.070 secs (user 14.470+0.000 sys 1.580+0.000)
Sun, 15 Mar 2015 18:58:56 +0900 similar: sort files not by object id but by path for stable result
Yuya Nishihara <yuya@tcha.org> [Sun, 15 Mar 2015 18:58:56 +0900] rev 31579
similar: sort files not by object id but by path for stable result Perhaps the original implementation would want to sort added/removed files alphabetically, but actually it did sort fctx objects by memory location. This patch removes the use of set()s in order to preserve the order of added/removed files. addedfiles.remove() becomes quadratic, but its cost appears not dominant. Anyway, the quadratic behavior will be eliminated by the next patch. Benchmark with 50k added/removed files, on tmpfs: $ mkdir src $ for n in `seq 0 49`; do > mkdir `printf src/%02d $n` > done $ for n in `seq 0 49999`; do > f=`printf src/%02d/%05d $(($n/1000)) $n` > dd if=/dev/urandom of=$f bs=8k count=1 status=none > done $ hg ci -qAm 'add 50k files of random content' $ mv src dest $ hg addremove --dry-run --time -q original: real 16.550 secs (user 15.000+0.000 sys 1.540+0.000) this patch: real 16.730 secs (user 15.280+0.000 sys 1.440+0.000)
Sun, 12 Mar 2017 01:34:17 -0800 debugfsinfo: print fstype information
Jun Wu <quark@fb.com> [Sun, 12 Mar 2017 01:34:17 -0800] rev 31578
debugfsinfo: print fstype information Since we have osutil.getfstype, it'll be handy if "debugfsinfo" prints it.
Sun, 12 Mar 2017 01:03:23 -0800 util: enable hardlink for copyfile
Jun Wu <quark@fb.com> [Sun, 12 Mar 2017 01:03:23 -0800] rev 31577
util: enable hardlink for copyfile This patch removes the global variable "allowhardlinks" that disables hardlink in all cases, so hardlink gets enabled if the filesystem type is whitelisted. Third party extensions wanting to enable hardlink support unconditionally can replace "_hardlinkfswhitelist.__contains__".
Sun, 12 Mar 2017 00:26:20 -0800 hghave: add a check about whitelisted filesystem that supports hardlink
Jun Wu <quark@fb.com> [Sun, 12 Mar 2017 00:26:20 -0800] rev 31576
hghave: add a check about whitelisted filesystem that supports hardlink This is needed for the test added by the next patch.
Sun, 12 Mar 2017 00:23:07 -0800 util: disable hardlink for copyfile if fstype is outside a whitelist
Jun Wu <quark@fb.com> [Sun, 12 Mar 2017 00:23:07 -0800] rev 31575
util: disable hardlink for copyfile if fstype is outside a whitelist Since osutil.getfstype is available, use it to detect filesystem types. The whitelist currently includes common local filesystems on Linux where they should have good hardlink support. We may add new filesystems for other platforms later.
Tue, 21 Mar 2017 17:39:49 -0400 revlog: use pycompat.maplist to eagerly evaluate map on Python 3
Augie Fackler <augie@google.com> [Tue, 21 Mar 2017 17:39:49 -0400] rev 31574
revlog: use pycompat.maplist to eagerly evaluate map on Python 3 According to Pulkit, this should fix `hg status --all` on Python 3.
Tue, 21 Mar 2017 22:47:49 -0700 py3: stop exporting urlparse from pycompat and util (API)
Gregory Szorc <gregory.szorc@gmail.com> [Tue, 21 Mar 2017 22:47:49 -0700] rev 31573
py3: stop exporting urlparse from pycompat and util (API) There are no consumers of this in tree. Functions formerly available on this object/module can now be accessed via {pycompat,util}.urlreq.
Tue, 21 Mar 2017 22:46:17 -0700 check-code: recommend util.urlreq when importing urlparse
Gregory Szorc <gregory.szorc@gmail.com> [Tue, 21 Mar 2017 22:46:17 -0700] rev 31572
check-code: recommend util.urlreq when importing urlparse
Tue, 21 Mar 2017 22:45:02 -0700 tests: use urlreq in tinyproxy.py
Gregory Szorc <gregory.szorc@gmail.com> [Tue, 21 Mar 2017 22:45:02 -0700] rev 31571
tests: use urlreq in tinyproxy.py This is our last consumer of util.urlparse.
Tue, 21 Mar 2017 22:39:52 -0700 bugzilla: use util.urlreq.urlparse
Gregory Szorc <gregory.szorc@gmail.com> [Tue, 21 Mar 2017 22:39:52 -0700] rev 31570
bugzilla: use util.urlreq.urlparse And stop saving a module variable because it shouldn't be necessary.
Tue, 21 Mar 2017 22:34:17 -0700 pycompat: define urlreq.urlparse and urlreq.unparse aliases
Gregory Szorc <gregory.szorc@gmail.com> [Tue, 21 Mar 2017 22:34:17 -0700] rev 31569
pycompat: define urlreq.urlparse and urlreq.unparse aliases Currently, we export urlparse via util.urlparse then call util.urlparse.urlparse() and util.urlparse.urlunparse() in a few places. This is the only url* module exported from pycompat, making it a one-off. So let's transition to urlreq to match everything else. Yes, we double import "urlparse" now on Python 2. This will be cleaned up in a subsequent patch. Also, the Python 3 functions trade in str/unicode not bytes. So we'll likely need to write a custom implementation that speaks bytes. But moving everyone to an abstracted API is a good first step.
Tue, 21 Mar 2017 22:28:16 -0700 pycompat: remove urlunquote alias
Gregory Szorc <gregory.szorc@gmail.com> [Tue, 21 Mar 2017 22:28:16 -0700] rev 31568
pycompat: remove urlunquote alias It is duplicated by urlreq.unquote and is unused. Kill it. We retain the imports because it is re-exported via util.urlparse, which is used elsewhere. Since we no longer access attributes of urlparse at module load time, this change /should/ result in that module reverting to a lazy module.
Tue, 21 Mar 2017 22:23:11 -0700 util: use urlreq.unquote
Gregory Szorc <gregory.szorc@gmail.com> [Tue, 21 Mar 2017 22:23:11 -0700] rev 31567
util: use urlreq.unquote pycompat.urlreq.unquote and pycompat.urlunquote effectively alias the same thing. pycompat.urlunquote is only used once in the code base. So let's switch to urlreq.unquote. "Effectively" in the above paragraph is because pycompat.urlreq.unquote aliases urllib.unquote and pycompat.urlunquote aliases urlparse.unquote on Python 2. You might think one of urllib.unquote and urlparse.unquote is an alias to the other, but you would be incorrect. In fact, these functions are copies of each other. There is even a comment in the CPython source code saying to keep them in sync. You can't make this up.
Tue, 21 Mar 2017 22:20:11 -0700 pycompat: alias urlreq.unquote to unquote_to_bytes
Gregory Szorc <gregory.szorc@gmail.com> [Tue, 21 Mar 2017 22:20:11 -0700] rev 31566
pycompat: alias urlreq.unquote to unquote_to_bytes Previously, urlreq.unquote aliased to urllib.parse.unquote, which returned a str/unicode. We like bytes, so switch urlreq.unquote to dispatch to urllib.parse.unquote_to_bytes. This required a minor helper function to register an alias under a different name from which it points. If this turns into a common pattern, we could likely teach _registeralias to accept tuple values defining the mapping. Until then, I didn't feel like adding complexity to _registeralias.
Sun, 19 Mar 2017 01:03:53 -0400 revsetlang: portably turn int into bytestring
Augie Fackler <augie@google.com> [Sun, 19 Mar 2017 01:03:53 -0400] rev 31565
revsetlang: portably turn int into bytestring
Mon, 20 Mar 2017 16:34:12 -0700 osutil: export a "getfstype" method
Jun Wu <quark@fb.com> [Mon, 20 Mar 2017 16:34:12 -0700] rev 31564
osutil: export a "getfstype" method This patch exports the "getfstype" method. So we can use it to enable hardlinks for known safe filesystems. The patch was tested manually via debugshell on a Linux system. "mercurial.osutil.getfstype" works as expected. It's hard to mount filesystem on user-space easily. I will add a test for real hardlink support to indirectly test this patch, after turning on real hardlinks support for certain whitelisted filesystems.
Mon, 20 Mar 2017 16:24:59 -0700 osutil: add a C function getting filesystem type
Jun Wu <quark@fb.com> [Mon, 20 Mar 2017 16:24:59 -0700] rev 31563
osutil: add a C function getting filesystem type Currently it only has Linux filesystems, according to my Linux manpage, built at 2016-03-15. The code uses "if" instead of "switch" because there could be some duplicated values.
Mon, 20 Mar 2017 15:43:27 -0700 setup: test some header files
Jun Wu <quark@fb.com> [Mon, 20 Mar 2017 15:43:27 -0700] rev 31562
setup: test some header files The next patch will use "statfs", which requires different header files on different platforms. Linux: sys/vfs.h or sys/statfs.h FreeBSD or OSX: sys/param.h and sys/mount.h Therefore test them so we can include the correct ones.
Mon, 20 Mar 2017 15:11:18 -0700 setup: detect statfs
Jun Wu <quark@fb.com> [Mon, 20 Mar 2017 15:11:18 -0700] rev 31561
setup: detect statfs statfs is not defined by POSIX but is available in various systems to help decide filesystem type. Let's detect it and set the macro HAVE_STATFS.
Mon, 20 Mar 2017 15:31:21 -0700 setup: add a function to test header files
Jun Wu <quark@fb.com> [Mon, 20 Mar 2017 15:31:21 -0700] rev 31560
setup: add a function to test header files
Mon, 20 Mar 2017 15:28:08 -0700 setup: split "hasfunction" to test arbitrary code
Jun Wu <quark@fb.com> [Mon, 20 Mar 2017 15:28:08 -0700] rev 31559
setup: split "hasfunction" to test arbitrary code The next patch wants to test include files.
Tue, 14 Mar 2017 17:43:44 -0700 rebase: add flag to require destination
Ryan McElroy <rmcelroy@fb.com> [Tue, 14 Mar 2017 17:43:44 -0700] rev 31558
rebase: add flag to require destination In some mercurial workflows, the default destination for rebase does not always work well and can lead to confusing behavior. With this flag enabled, every rebase command will require passing an explicit destination, eliminating this confusion.
Tue, 14 Mar 2017 17:43:18 -0700 update: add flag to require update destination
Ryan McElroy <rmcelroy@fb.com> [Tue, 14 Mar 2017 17:43:18 -0700] rev 31557
update: add flag to require update destination In some mercurial workflows, the default destination for update does not always work well and can lead to confusing behavior. With this flag enabled, every update command will require passing an explicit destination, eliminating this confusion.
(0) -30000 -10000 -3000 -1000 -300 -100 -48 +48 +100 +300 +1000 +3000 +10000 tip