Mon, 20 Jul 2015 13:39:25 -0700 exchange: fix dead assignment
Martin von Zweigbergk <martinvonz@google.com> [Mon, 20 Jul 2015 13:39:25 -0700] rev 25896
exchange: fix dead assignment The assignment of the value from bundle2.processbundle() to 'r' is unused. It is currently the same as its third argument (if given), and since that argument may eventually go away (according to the method's docstring), let's reassign the return value to 'op' instead to better prepare for that.
Mon, 20 Jul 2015 13:35:19 -0700 exchange: s/phase/bookmark/ in _pushb2bookmarks()
Martin von Zweigbergk <martinvonz@google.com> [Mon, 20 Jul 2015 13:35:19 -0700] rev 25895
exchange: s/phase/bookmark/ in _pushb2bookmarks()
Fri, 31 Jul 2015 15:11:07 -0700 histedit: backout ebb5bb9bc32e stable
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 31 Jul 2015 15:11:07 -0700] rev 25894
histedit: backout ebb5bb9bc32e The faulty changeset use obsolescence marker to roll the repository back on --abort. This is a problematic approach because --abort should be as close as an actually transaction rollback as possible stripping all created data from the repository (cf `hg rebase --abort` stripping all created changesets). Instead ebb5bb9bc32e made all content created during the aborted histedit still available in the repository adding obsolescence marker to make them hidden. This will cause trouble to evolution user as a re-run of the same histedit (with success) will likely result in the very same node to be "recreated" while obsolescence marker would be in place for them. And canceling an obsoletion is still a fairly complicated process. This also rollback using obsmarkers instead of strip to clean up temporary node on successful histedit run because the two change were not split in separated changeset. Rolling that part back does not have significant consequence a will have to be resubmitted independently
Sun, 02 Aug 2015 21:56:38 -0700 test-bookmarks.t: avoid nested repo
Siddharth Agarwal <sid0@fb.com> [Sun, 02 Aug 2015 21:56:38 -0700] rev 25893
test-bookmarks.t: avoid nested repo This is (a) pretty unnecessary and (b) breaks tests for the third-party hgwatchman extension, which doesn't support nested repos.
Sun, 02 Aug 2015 12:16:19 +0900 revlog: remove unused shaoffset constants
Yuya Nishihara <yuya@tcha.org> [Sun, 02 Aug 2015 12:16:19 +0900] rev 25892
revlog: remove unused shaoffset constants Call sites were removed at 61c9bc3da402, "revlog: remove lazy index".
Sun, 02 Aug 2015 01:14:11 +0900 revlog: correct comment about size of v0 index format
Yuya Nishihara <yuya@tcha.org> [Sun, 02 Aug 2015 01:14:11 +0900] rev 25891
revlog: correct comment about size of v0 index format
Mon, 03 Aug 2015 11:34:27 -0700 merge with stable
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 03 Aug 2015 11:34:27 -0700] rev 25890
merge with stable
Fri, 31 Jul 2015 11:56:28 -0500 Added signature for changeset 21aa1c313b05 stable
Matt Mackall <mpm@selenic.com> [Fri, 31 Jul 2015 11:56:28 -0500] rev 25889
Added signature for changeset 21aa1c313b05
Fri, 31 Jul 2015 11:56:24 -0500 Added tag 3.5 for changeset 21aa1c313b05 stable
Matt Mackall <mpm@selenic.com> [Fri, 31 Jul 2015 11:56:24 -0500] rev 25888
Added tag 3.5 for changeset 21aa1c313b05
Fri, 31 Jul 2015 10:49:15 -0500 i18n: fix unclosed inline span in pt_BR stable 3.5
Matt Mackall <mpm@selenic.com> [Fri, 31 Jul 2015 10:49:15 -0500] rev 25887
i18n: fix unclosed inline span in pt_BR This was causing test-gendoc.t to complain: WARNING: Inline interpreted text or phrase reference start-string without end-string.
Fri, 31 Jul 2015 10:26:57 -0500 merge with i18n stable
Matt Mackall <mpm@selenic.com> [Fri, 31 Jul 2015 10:26:57 -0500] rev 25886
merge with i18n
Fri, 31 Jul 2015 18:39:48 +0900 i18n-ja: synchronized with 7fcad0c4ef8c stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Fri, 31 Jul 2015 18:39:48 +0900] rev 25885
i18n-ja: synchronized with 7fcad0c4ef8c
Wed, 22 Jul 2015 16:57:11 +0100 convert: when converting from Perforce use original local encoding by default stable
Eugene Baranov <eug.baranov@gmail.com> [Wed, 22 Jul 2015 16:57:11 +0100] rev 25884
convert: when converting from Perforce use original local encoding by default On Windows Perforce command line client uses default system locale to encode output. Using 'latin_1' causes locale-specific characters to be replaced with question marks. With this patch we will use default locale by default whilst allowing to specify it explicity with 'convert.p4.encoding' config option. This is a potentially breaking change for any scripts relying on output treated as in 'latin_1' encoding. Also because hgext.convert.convcmd overwrites detected default system locale with UTF-8 we had to introduce an import cycle in hgext.convert.p4 to retrieve originally detected encoding from hgext.convert.convcmd.
Wed, 29 Jul 2015 11:37:36 -0300 i18n-pt_BR: synchronized with 3e84f40232c7 stable
Wagner Bruna <wbruna@softwareexpress.com.br> [Wed, 29 Jul 2015 11:37:36 -0300] rev 25883
i18n-pt_BR: synchronized with 3e84f40232c7
Thu, 30 Jul 2015 00:58:05 +0100 convert: when getting file from Perforce concatenate data at the end stable
Eugene Baranov <eug.baranov@gmail.com> [Thu, 30 Jul 2015 00:58:05 +0100] rev 25882
convert: when getting file from Perforce concatenate data at the end As it turned out, even when getting relatively small files, concatenating string data every time when new chunk is received is very inefficient. Maintaining a string list of data chunks and concatenating everything in one go at the end seems much more efficient - in my testing it made getting 40 MB file 7 times faster, whilst converting of a particularly big changelist with some big files went down from 20 hours to 3 hours.
Sat, 18 Jul 2015 17:10:28 -0700 help: scripting help topic stable
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 18 Jul 2015 17:10:28 -0700] rev 25881
help: scripting help topic There are a lot of non-human consumers of Mercurial. And the challenges and considerations for machines consuming Mercurial is significantly different from what humans face. I think there are enough special considerations around how machines consume Mercurial that a dedicated help topic is warranted. I concede the audience for this topic is probably small compared to the general audience. However, lots of normal Mercurial users do things like create one-off shell scripts for common workflows that I think this is useful enough to be in the install (as opposed to, say, a wiki page - which most users will likely never find). This text is by no means perfect. But you have to start somewhere. I think I did cover the important parts, though.
(0) -10000 -3000 -1000 -300 -100 -16 +16 +100 +300 +1000 +3000 +10000 tip