Sat, 11 Apr 2020 00:21:37 +0900 rust-chg: leverage impl trait at argument position
Yuya Nishihara <yuya@tcha.org> [Sat, 11 Apr 2020 00:21:37 +0900] rev 44693
rust-chg: leverage impl trait at argument position Differential Revision: https://phab.mercurial-scm.org/D8401
Mon, 13 Apr 2020 16:30:13 +0300 setup: link osutil.so to libsocket on Solaris/illumos (issue6299) stable
Alexander Pyhalov <apyhalov@gmail.com> [Mon, 13 Apr 2020 16:30:13 +0300] rev 44692
setup: link osutil.so to libsocket on Solaris/illumos (issue6299)
Mon, 13 Apr 2020 01:19:09 -0400 revset: import `unstable()` from the evolve extension
Matt Harbison <matt_harbison@yahoo.com> [Mon, 13 Apr 2020 01:19:09 -0400] rev 44691
revset: import `unstable()` from the evolve extension Differential Revision: https://phab.mercurial-scm.org/D8404
Fri, 10 Apr 2020 22:33:14 +0200 fastexport: make a diagnostics message more localizable
Joerg Sonnenberger <joerg@bec.de> [Fri, 10 Apr 2020 22:33:14 +0200] rev 44690
fastexport: make a diagnostics message more localizable Differential Revision: https://phab.mercurial-scm.org/D8398
Fri, 10 Apr 2020 21:38:08 +0900 rust-chg: use "crate::" to import local modules
Yuya Nishihara <yuya@tcha.org> [Fri, 10 Apr 2020 21:38:08 +0900] rev 44689
rust-chg: use "crate::" to import local modules I feel it's easier to follow to resolve modules from the crate root than relative path from self module. Differential Revision: https://phab.mercurial-scm.org/D8400
Fri, 10 Apr 2020 21:35:16 +0900 rust-chg: upgrade to 2018 edition and remove useless extern crates
Yuya Nishihara <yuya@tcha.org> [Fri, 10 Apr 2020 21:35:16 +0900] rev 44688
rust-chg: upgrade to 2018 edition and remove useless extern crates Differential Revision: https://phab.mercurial-scm.org/D8399
Thu, 09 Apr 2020 16:06:03 +0530 mergestate: store about files resolved in favour of other
Pulkit Goyal <7895pulkit@gmail.com> [Thu, 09 Apr 2020 16:06:03 +0530] rev 44687
mergestate: store about files resolved in favour of other Committing a merge sometimes wrongly creates a new filenode where it can re-use an existing one. This happens because the commit code does it's own calculation and does not know what happened on merge. This starts storing information in mergestate about files which were automatically merged and the other/remote version of file was used. We need this information at commit to pick the filenode parent for the new commit. This issue was found by Pierre-Yves David and idea to store the relevant parts in mergestate is also suggested by him. Somethings which can be further investigated are: 1) refactoring of commit logic more to depend on this information 2) maybe a more generic solution? Differential Revision: https://phab.mercurial-scm.org/D8392
Thu, 09 Apr 2020 15:44:21 -0400 histedit: add test that an invalid editor doesn't bork client state
Augie Fackler <augie@google.com> [Thu, 09 Apr 2020 15:44:21 -0400] rev 44686
histedit: add test that an invalid editor doesn't bork client state We had a report of a situation like this borking a user at Google, but I can't reproduce it in a test. Let's at least backstop the issue with a test, so we don't accidentally introduce such a bug... Differential Revision: https://phab.mercurial-scm.org/D8391
Tue, 31 Mar 2020 23:25:26 +0900 rust-chg: silence warning about dated coding style
Yuya Nishihara <yuya@tcha.org> [Tue, 31 Mar 2020 23:25:26 +0900] rev 44685
rust-chg: silence warning about dated coding style Differential Revision: https://phab.mercurial-scm.org/D8384
Mon, 19 Nov 2018 20:50:45 +0900 rust-chg: update name of the server process
Yuya Nishihara <yuya@tcha.org> [Mon, 19 Nov 2018 20:50:45 +0900] rev 44684
rust-chg: update name of the server process This is a copy of updateprocname() of hgclient.c. At this point, rust-chg is basically functional. I did dogfooding for a couple of weeks in 2018. There are a few remaining tasks: a. loop detection by CHGINTERNALMARK b. forward unsupported commands (notably serve -d) to real hg c. better handling of early server exception d. modernize codebase (2018 edition, impl trait, async/await) For (d), we'll probably want to switch to async-std, but I'm thinking of upgrading to Tokio 0.2 as an intermediate step since process API isn't ported to async-std yet. I'm pretty sure future migration to async-std will be painless compared to the mass rewrite from futures-0.1 to 0.3. https://github.com/async-rs/async-std/issues/22 Differential Revision: https://phab.mercurial-scm.org/D8383
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 tip