Thu, 04 Feb 2016 11:18:50 +0000 readme: point to mercurial-scm.org instead of selenic.com stable
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 04 Feb 2016 11:18:50 +0000] rev 1603
readme: point to mercurial-scm.org instead of selenic.com
Thu, 04 Feb 2016 11:17:09 +0000 merge with stable (Mercurial 3.7 is out) stable
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 04 Feb 2016 11:17:09 +0000] rev 1602
merge with stable (Mercurial 3.7 is out)
Thu, 04 Feb 2016 11:13:38 +0000 tests: register expected difference for Mercurial 3.6 mercurial-3.6
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 04 Feb 2016 11:13:38 +0000] rev 1601
tests: register expected difference for Mercurial 3.6
Thu, 04 Feb 2016 11:07:44 +0000 tests: register expected difference for Mercurial 3.5 mercurial-3.5
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 04 Feb 2016 11:07:44 +0000] rev 1600
tests: register expected difference for Mercurial 3.5
Thu, 04 Feb 2016 10:24:26 +0000 test: adapt to 3.6 help changes stable
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 04 Feb 2016 10:24:26 +0000] rev 1599
test: adapt to 3.6 help changes
Thu, 04 Feb 2016 02:46:40 -0800 evolve: make split respect rev args passed without --rev or -r
Kostia Balytskyi <ikostia@fb.com> [Thu, 04 Feb 2016 02:46:40 -0800] rev 1598
evolve: make split respect rev args passed without --rev or -r Currently, if one runs `hg split .` or `hg split`, it will fail with an exception. This happens becuase we only expect revision args to be passed as --rev/-r ones and don't treat unnamed args properly or add default values if no args are provided.
Thu, 04 Feb 2016 01:19:14 +0000 evolve: write our own custom evolvestate file
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 04 Feb 2016 01:19:14 +0000] rev 1597
evolve: write our own custom evolvestate file Since for ever, we were using 'graftstate' to record the node currently being evolve and allow 'hg evolve --continue' we now move to our on 'evolvestate' file. This remove and issue with 'hg summary' listing interrupted evolve as graft. This also open the way for storing more data into that file and allow proper --abort and --continue of the whole evolve operation (and not just the last one). The whole thing is very hacky but at least there is some progress. Thanks goes to Shusen Liu for initiating this work.
Thu, 04 Feb 2016 10:16:52 +0000 readme: update readme for issue 4966
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 04 Feb 2016 10:16:52 +0000] rev 1596
readme: update readme for issue 4966
Wed, 03 Feb 2016 23:21:50 +0000 test: back hash change from 'extra' content change out
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 03 Feb 2016 23:21:50 +0000] rev 1595
test: back hash change from 'extra' content change out The changesets 13701c3fed9c, 3e907ff1981f and 54394d2aaf5e were introduced to handle a change to the way extra were carried out by various command in core. This had to be backout for 3.7.1 as is broken multiple third party extension. We backout the test update as a result. Core changesets performing the backout: ce9696193175::b698abf971e7
Fri, 22 Jan 2016 21:41:59 +0900 evolve: close transaction if conflict is detected in relocate (issue4966)
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Fri, 22 Jan 2016 21:41:59 +0900] rev 1594
evolve: close transaction if conflict is detected in relocate (issue4966) Before this patch, transaction is aborted, if conflict is detected at merging while "hg evolve". Since 8f2ff40fe9c9 (or 3.6) of Mercurial, aborting transaction discards all dirstate changes inside transaction scope for "transactional dirstate" (see below wiki page for detail about it). https://mercurial.selenic.com/wiki/DirstateTransactionPlan Therefore, just aborting transaction causes unchanged (and unexpected) dirstate, even though subsequent commands require dirstate changes while "hg evolve". To keep dirstate changes while "hg evolve", this patch closes current running transaction, if conflict is detected in relocate(), even though exception is raised as usual. Even though "save dirstate and restore it after aborting transaction" like shelve._aborttransaction() of Mercurial can also solve this issue, this patch chose closing transaction for similarity with failure for conflict at "hg unshelve". In addition to it, closing transaction can keep any previous (implicit) changes. In newly added test, there is an additional ancestor revision, which "will be evolved safely". It is used to examine whether failure for conflict doesn't discard already relocated revision(s) while "hg evolve". It is fact for current implementation that "hg evolve" relocates each revisions in separated transactions and already relocated ones are never discarded, even if subsequent relocation fails. Though, this examination is useful to detect unintentional regression in the future.
(0) -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 tip