Wed, 26 Nov 2014 15:37:01 -0800 manifest: document the extra letter in working copy manifest node
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 26 Nov 2014 15:37:01 -0800] rev 23410
manifest: document the extra letter in working copy manifest node As the second developer to get confused by this in November, I'm adding some documentation for the next poor soul.
Fri, 28 Nov 2014 10:59:02 -0800 hgweb: send proper HTTP response after uncaught exception stable
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 28 Nov 2014 10:59:02 -0800] rev 23409
hgweb: send proper HTTP response after uncaught exception This patch fixes a bug where hgweb would send an incomplete HTTP response. If an uncaught exception is raised when hgweb is processing a request, hgweb attempts to send a generic error response and log that exception. The server defaults to chunked transfer coding. If an uncaught exception occurred, it was sending the error response string / chunk properly. However, RFC 7230 Section 4.1 mandates a 0 size last chunk be sent to indicate end of the entity body. hgweb was failing to send this last chunk. As a result, properly written HTTP clients would assume more data was coming and they would likely time out waiting for another chunk to arrive. Mercurial's own test harness was paving over the improper HTTP behavior by not attempting to read the response body if the status code was 500. This incorrect workaround was added in ba6577a19656 and has been removed with this patch.
Sun, 30 Nov 2014 20:06:53 +0100 tests: test rebase of merge of target ancestors
Mads Kiilerich <madski@unity3d.com> [Sun, 30 Nov 2014 20:06:53 +0100] rev 23408
tests: test rebase of merge of target ancestors
Sun, 30 Nov 2014 19:36:03 +0100 tests: test coverage of parent order with p1 outside rebase set
Mads Kiilerich <madski@unity3d.com> [Sun, 30 Nov 2014 19:36:03 +0100] rev 23407
tests: test coverage of parent order with p1 outside rebase set
Sun, 30 Nov 2014 19:35:54 +0100 tests: add test for rebasing merges with ancestors of the rebase destination
Mads Kiilerich <madski@unity3d.com> [Sun, 30 Nov 2014 19:35:54 +0100] rev 23406
tests: add test for rebasing merges with ancestors of the rebase destination This shows sub-optimal behaviour. The user gets a merge prompt that it is very hard to justify.
Sun, 30 Nov 2014 19:26:53 +0100 merge: 0 is a valid ancestor different from None
Mads Kiilerich <madski@unity3d.com> [Sun, 30 Nov 2014 19:26:53 +0100] rev 23405
merge: 0 is a valid ancestor different from None Most internal functions can take either a hash or an integer. Merge did however not handle 0 as revision 0. Now it does.
Thu, 27 Nov 2014 12:25:01 -0600 merge with stable
Matt Mackall <mpm@selenic.com> [Thu, 27 Nov 2014 12:25:01 -0600] rev 23404
merge with stable
Tue, 25 Nov 2014 19:40:54 -0800 revert: look for copy information for all local modifications stable
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 25 Nov 2014 19:40:54 -0800] rev 23403
revert: look for copy information for all local modifications Renaming a file over an existing one marks the file as modified. So we track rename source in modified file too.
Mon, 24 Nov 2014 18:42:56 -0800 rename: properly report removed and added file as modified (issue4458) stable
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 24 Nov 2014 18:42:56 -0800] rev 23402
rename: properly report removed and added file as modified (issue4458) The result of 'hg rm' + 'hg rename' disagreed with the one from 'hg rename --force'. We align them on 'hg move --force' because it agrees with what 'hg status' says after the commit. Stopping reporting a modified file as added puts an end to the hg revert confusion in this situation (issue4458). However, reporting the file as modified also prevents revert from restoring the copy source. We fix this in a later changeset. Git diff also stop reporting the add in the middle of the chain as add. Not sure how important (and even wrong) it is.
Wed, 26 Nov 2014 14:54:16 -0800 manifest: fix a bug where working copy file 'add' mark was buggy stable
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 26 Nov 2014 14:54:16 -0800] rev 23401
manifest: fix a bug where working copy file 'add' mark was buggy Because the same dictionary was used to (1) get node from parent and (2) store annotated version, we could end up with buggy values. For example with a chain of renames: $ hg mv b c $ hg mv a b The value from 'b' would be updated as "<old-a>a", then the value of c would be updated as "<old-b>a'. With the current dictionary sharing this ends up with: '<new-c>' == '<old-a>aa' This value is double-wrong as we should use '<old-b>' and a single 'a'. We now use a read-only value for lookup. The 'test-rename.t' test is impacted because such a chained added file is suddenly detected as such.
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip