Thu, 18 May 2017 18:00:52 -0400 cmdutil: use repo[None].walk instead of repo.walk
Augie Fackler <augie@google.com> [Thu, 18 May 2017 18:00:52 -0400] rev 32401
cmdutil: use repo[None].walk instead of repo.walk
Thu, 18 May 2017 18:00:38 -0400 largefiles: use repo[None].walk instead of repo.walk
Augie Fackler <augie@google.com> [Thu, 18 May 2017 18:00:38 -0400] rev 32400
largefiles: use repo[None].walk instead of repo.walk
Tue, 25 Apr 2017 17:43:30 -0700 parsers: add version to help detect breaking binary changes
Jun Wu <quark@fb.com> [Tue, 25 Apr 2017 17:43:30 -0700] rev 32399
parsers: add version to help detect breaking binary changes
Tue, 25 Apr 2017 17:36:59 -0700 osutil: add version to help detect breaking binary changes
Jun Wu <quark@fb.com> [Tue, 25 Apr 2017 17:36:59 -0700] rev 32398
osutil: add version to help detect breaking binary changes See the previous patch for why.
Tue, 25 Apr 2017 17:38:36 -0700 mpatch: add version to help detect breaking binary changes
Jun Wu <quark@fb.com> [Tue, 25 Apr 2017 17:38:36 -0700] rev 32397
mpatch: add version to help detect breaking binary changes
Tue, 25 Apr 2017 17:40:13 -0700 diffhelpers: add version to help detect breaking binary changes
Jun Wu <quark@fb.com> [Tue, 25 Apr 2017 17:40:13 -0700] rev 32396
diffhelpers: add version to help detect breaking binary changes
Tue, 25 Apr 2017 17:45:48 -0700 base85: add version to help detect breaking binary changes
Jun Wu <quark@fb.com> [Tue, 25 Apr 2017 17:45:48 -0700] rev 32395
base85: add version to help detect breaking binary changes
Tue, 25 Apr 2017 17:34:41 -0700 bdiff: add version to help detect breaking binary changes
Jun Wu <quark@fb.com> [Tue, 25 Apr 2017 17:34:41 -0700] rev 32394
bdiff: add version to help detect breaking binary changes Previously, we have no way to detect if a compiled .so file could be used or not, and blindly load it if it exists. Usually we carefully maintain compatibility of .so and fallback to pure code gracefully. But if we stick to the rules, certain nice changes will be impossible to make in a clean way. This patch adds a "version" constant to the module so we can detect inconsistency and take appropriate actions (warn, abort, fallback to pure, run make automatically) in module loader.
Sat, 20 May 2017 03:10:23 +0200 obsmarker: add an experimental flag controlling "operation" recording
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 20 May 2017 03:10:23 +0200] rev 32393
obsmarker: add an experimental flag controlling "operation" recording It seems better to introduce the experiment behind a flag for now as there are multiple concerns around the feature: * Storing operation increase the size of obsolescence markers significantly (+10-20%). * It performs poorly when exchanging markers (cannot combine command names, command name might be unknown remotely, etc)
Fri, 19 May 2017 19:46:45 -0700 run-tests: remove references to Python 2.6
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 19 May 2017 19:46:45 -0700] rev 32392
run-tests: remove references to Python 2.6 These are the obvious ones. There is tons of code in this file implementing features from unittest that weren't present in Python 2.6. But that's for other patches.
Thu, 18 May 2017 17:13:32 -0400 dirstate: mark {begin,end}parentchange as deprecated (API)
Augie Fackler <augie@google.com> [Thu, 18 May 2017 17:13:32 -0400] rev 32391
dirstate: mark {begin,end}parentchange as deprecated (API)
Thu, 18 May 2017 17:11:24 -0400 merge: migrate to context manager for changing dirstate parents
Augie Fackler <augie@google.com> [Thu, 18 May 2017 17:11:24 -0400] rev 32390
merge: migrate to context manager for changing dirstate parents
Thu, 18 May 2017 17:11:14 -0400 localrepo: migrate to context manager for changing dirstate parents
Augie Fackler <augie@google.com> [Thu, 18 May 2017 17:11:14 -0400] rev 32389
localrepo: migrate to context manager for changing dirstate parents
Thu, 18 May 2017 17:11:07 -0400 context: migrate to context manager for changing dirstate parents
Augie Fackler <augie@google.com> [Thu, 18 May 2017 17:11:07 -0400] rev 32388
context: migrate to context manager for changing dirstate parents
Thu, 18 May 2017 17:11:01 -0400 rebase: migrate to context manager for changing dirstate parents
Augie Fackler <augie@google.com> [Thu, 18 May 2017 17:11:01 -0400] rev 32387
rebase: migrate to context manager for changing dirstate parents
Thu, 18 May 2017 17:10:53 -0400 mq: migrate to context manager for changing dirstate parents
Augie Fackler <augie@google.com> [Thu, 18 May 2017 17:10:53 -0400] rev 32386
mq: migrate to context manager for changing dirstate parents
Thu, 18 May 2017 17:10:30 -0400 dirstate: introduce new context manager for marking dirstate parent changes
Augie Fackler <augie@google.com> [Thu, 18 May 2017 17:10:30 -0400] rev 32385
dirstate: introduce new context manager for marking dirstate parent changes
Fri, 19 May 2017 17:01:34 -0700 contrib: make editmergeps able to work with notepad++
Kostia Balytskyi <ikostia@fb.com> [Fri, 19 May 2017 17:01:34 -0700] rev 32384
contrib: make editmergeps able to work with notepad++ Notepad++ has a different FIRSTLINE argument, so needs special handling.
Fri, 19 May 2017 17:00:55 -0700 contrib: make editmergeps able to work with Windows GUI editors
Kostia Balytskyi <ikostia@fb.com> [Fri, 19 May 2017 17:00:55 -0700] rev 32383
contrib: make editmergeps able to work with Windows GUI editors Using Start-Process -Wait makes it wait until the process finishes, which is necesssary for Windows GUI applications. My short testing also demonstrated that it does not hurt with command line vim.
Sat, 09 Jan 2016 23:24:52 +0900 extensions: show deprecation warning for the use of cmdutil.command
Yuya Nishihara <yuya@tcha.org> [Sat, 09 Jan 2016 23:24:52 +0900] rev 32382
extensions: show deprecation warning for the use of cmdutil.command Since this is a fundamental API for extensions, we set 1-year period until actually removing it.
Sat, 13 May 2017 15:41:50 +0900 extensions: prohibit registration of command without using @command (API)
Yuya Nishihara <yuya@tcha.org> [Sat, 13 May 2017 15:41:50 +0900] rev 32381
extensions: prohibit registration of command without using @command (API) Detect the problem earlier for better error indication. I'm tired of teaching users that the mq extension is not guilty but the third-party extension is. https://bitbucket.org/tortoisehg/thg/issues?q=%27norepo%27
Sun, 14 May 2017 15:46:45 +0900 extensions: optionally print hint on import failure
Yuya Nishihara <yuya@tcha.org> [Sun, 14 May 2017 15:46:45 +0900] rev 32380
extensions: optionally print hint on import failure Test will be added by the next patch.
Sun, 14 May 2017 15:41:27 +0900 error: add hint to ProgrammingError
Yuya Nishihara <yuya@tcha.org> [Sun, 14 May 2017 15:41:27 +0900] rev 32379
error: add hint to ProgrammingError As the hint isn't shown by the default exception handler, we need to print it manually. I've copied the "** " style from _exceptionwarning().
Mon, 08 May 2017 22:14:56 +0900 registrar: unindent superfluous "if True" block
Yuya Nishihara <yuya@tcha.org> [Mon, 08 May 2017 22:14:56 +0900] rev 32378
registrar: unindent superfluous "if True" block
Mon, 08 May 2017 22:08:40 +0900 registrar: switch @command decorator to class
Yuya Nishihara <yuya@tcha.org> [Mon, 08 May 2017 22:08:40 +0900] rev 32377
registrar: switch @command decorator to class It overrides _funcregistrarbase._doregister() since the structure of the command table is quite different.
Sat, 09 Jan 2016 23:07:20 +0900 registrar: move cmdutil.command to registrar module (API)
Yuya Nishihara <yuya@tcha.org> [Sat, 09 Jan 2016 23:07:20 +0900] rev 32376
registrar: move cmdutil.command to registrar module (API) cmdutil.command wasn't a member of the registrar framework only for a historical reason. Let's make that happen. This patch keeps cmdutil.command as an alias for extension compatibility.
Sat, 13 May 2017 17:53:55 +0900 gendoc: make sure locale path is set before loading any modules
Yuya Nishihara <yuya@tcha.org> [Sat, 13 May 2017 17:53:55 +0900] rev 32375
gendoc: make sure locale path is set before loading any modules Otherwise some messages wouldn't be translated depending on when the util was loaded.
Thu, 18 May 2017 12:49:10 -0700 fsmonitor: don't attempt state-leave if we didn't state-enter
Wez Furlong <wez@fb.com> [Thu, 18 May 2017 12:49:10 -0700] rev 32374
fsmonitor: don't attempt state-leave if we didn't state-enter The state-enter command may not have been successful; for example, the watchman client session may have timed out if the user was busy/idle for a long period during a merge conflict resolution earlier in processing a rebase for a stack of diffs. It's cleaner (from the perspective of the watchman logs) to avoid issuing the state-leave command in these cases. Test Plan: ran `hg rebase --tool :merge -r '(draft() & date(-14)) - master::' -d master` and didn't observe any errors in the watchman logs or in the output from `watchman -p -j <<<'["subscribe", "/data/users/wez/fbsource", "wez", {"expression": ["name", ".hg/updatestate"]}]'`
Thu, 18 May 2017 12:48:07 -0700 fsmonitor: acquire localrepo.wlock prior to emitting hg.update state
Wez Furlong <wez@fb.com> [Thu, 18 May 2017 12:48:07 -0700] rev 32373
fsmonitor: acquire localrepo.wlock prior to emitting hg.update state we see some weird things in the watchman logs where the mercurial process is seemingly confused about which hg.update state it is publishing through watchman. On closer examination, we're seeing conflicting pids for the clients involved and this implies a race. To resolve this, we extend the wlock around the state-enter/state-leave events that are emitted to watchman. Test Plan: Some manual testing: In one window, run this, and then checkout a different rev: ``` $ watchman -p -j <<<'["subscribe", "/data/users/wez/fbsource", "wez", {"expression": ["name", ".hg/updatestate"]}]' { "version": "4.9.0", "subscribe": "wez", "clock": "c:1495034090:814028:1:312576" } { "state-enter": "hg.update", "version": "4.9.0", "clock": "c:1495034090:814028:1:312596", "unilateral": true, "subscription": "wez", "metadata": { "status": "ok", "distance": 125, "rev": "a1275d79ffa6c58b53116c8ec401c275ca6c1e2a", "partial": false }, "root": "/data/users/wez/fbsource" } { "root": "/data/users/wez/fbsource", "metadata": { "status": "ok", "distance": 125, "rev": "a1275d79ffa6c58b53116c8ec401c275ca6c1e2a", "partial": false }, "subscription": "wez", "unilateral": true, "version": "4.9.0", "clock": "c:1495034090:814028:1:312627", "state-leave": "hg.update" } ``` Tailed the watchman log file and looked for invalid state assertion errors, then ran my `rebase-all` script to update/rebase all of my heads. Didn't trigger the error condition (but couldn't reliably trigger it previously anyway), and the output captured above shows that the states are being emitted correctly.
Fri, 19 May 2017 13:12:42 +0200 obsolete: move the 'isenabled' function at the top of the file
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 19 May 2017 13:12:42 +0200] rev 32372
obsolete: move the 'isenabled' function at the top of the file That is a simple and important function so having it at the top next to the related constant seems better.
(0) -30000 -10000 -3000 -1000 -300 -100 -50 -30 +30 +50 +100 +300 +1000 +3000 +10000 tip