Tue, 15 Mar 2016 17:25:18 +0000 discovery: remove a spurious print
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 15 Mar 2016 17:25:18 +0000] rev 1899
discovery: remove a spurious print
Mon, 14 Mar 2016 18:24:33 +0000 task: add index number to the output
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 14 Mar 2016 18:24:33 +0000] rev 1898
task: add index number to the output We are doing to use these number for easy movement in later changesets. The numbering will probably evolve over time but this is a good start.
Mon, 14 Mar 2016 18:11:52 +0000 stack: fix printing order in case of unstability
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 14 Mar 2016 18:11:52 +0000] rev 1897
stack: fix printing order in case of unstability The stack was displayed using revision number order, this give good result in the simple case (straight stack) but give bad result when the stack is not linear because of unstability. We fixes it by reusing the evolution logic for sorting. As we do not live next to evolution yet, we duplicated this logic for now.
Mon, 14 Mar 2016 17:48:31 +0000 stack: exclude obsolete changeset from the set
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 14 Mar 2016 17:48:31 +0000] rev 1896
stack: exclude obsolete changeset from the set We care about relevant changeset, obsolete have a new version somewhere and we don't care about the old one in our display. In case of unstability, the ordering used is still wrong.
Mon, 14 Mar 2016 17:37:39 +0000 stack: add a very first version of stack display with 'hg topic --list'
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 14 Mar 2016 17:37:39 +0000] rev 1895
stack: add a very first version of stack display with 'hg topic --list' This mark the first step toward a set of feature dedicated to displaying and moving within the current stack of work. Everything is still super basic so don't look too much at the feature. The goals of this changeset are: * having a flag to trigger the feature * having a basic (imperfect selection mechanism)
Mon, 14 Mar 2016 17:09:02 +0000 topic: get 'Abort' from error, not 'util'
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 14 Mar 2016 17:09:02 +0000] rev 1894
topic: get 'Abort' from error, not 'util' The class live in 'mercurial.error'.
Mon, 14 Mar 2016 21:22:56 -0400 Makefile: meant tests-@ not tests-tip
Augie Fackler <raf@durin42.com> [Mon, 14 Mar 2016 21:22:56 -0400] rev 1893
Makefile: meant tests-@ not tests-tip
Sun, 13 Mar 2016 12:29:43 +0000 update: change default update destination to take topic in account
Pierre-Yves David <pierre-yves.david@fb.com> [Sun, 13 Mar 2016 12:29:43 +0000] rev 1892
update: change default update destination to take topic in account When within a branch update to ngtip(branch). When within a topic update to the top topic.
Sun, 13 Mar 2016 13:07:54 +0000 rebase: test default rebase destination behavior
Pierre-Yves David <pierre-yves.david@fb.com> [Sun, 13 Mar 2016 13:07:54 +0000] rev 1891
rebase: test default rebase destination behavior In future mercurial 3.8, rebase and merge share the same destination logic. So if merge work, rebase should work as well. However, we double test it to be sure. Especially, in 3.7 the logic is not shared so we have to introduce an extra hack to share it in this case.
Sun, 13 Mar 2016 23:44:04 +0000 topicmap: write and read format from disc
Pierre-Yves David <pierre-yves.david@fb.com> [Sun, 13 Mar 2016 23:44:04 +0000] rev 1890
topicmap: write and read format from disc To prevent too awful performance we allow writing and reading topicmap cache. This is done with a lot of code duplication from core because core is not extensible enough.
Mon, 14 Mar 2016 00:15:54 +0000 topicmap: ensure that 'served' view is updated with topicmap
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 14 Mar 2016 00:15:54 +0000] rev 1889
topicmap: ensure that 'served' view is updated with topicmap There is multiple place that explicitly update the 'served' branchmap to ensure it stay up to date. We ensure it use the proper topicmap in this case.
Mon, 14 Mar 2016 00:12:22 +0000 topicmap: move the monkey patching into a context manager
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 14 Mar 2016 00:12:22 +0000] rev 1888
topicmap: move the monkey patching into a context manager There is a couple of other place doing branchmap/topicmap update (of the served set), we'll have to set the monkey patching for them. This changeset is just doing the move to a context manager to make sure it is correct.
Sat, 12 Mar 2016 18:42:16 +0000 push: hackish handeling of new branch head from phase move
Pierre-Yves David <pierre-yves.david@fb.com> [Sat, 12 Mar 2016 18:42:16 +0000] rev 1887
push: hackish handeling of new branch head from phase move The current head checking mechanism is not expecting "head change" from phase movement. Topic allows that, changeset with a topic moving to public can create a new head. We introduce a hack to double check that no head were added at the transaction level to work around this.
Sat, 12 Mar 2016 18:19:27 +0000 push: allow pushing new topic to non-publishing server by default
Pierre-Yves David <pierre-yves.david@fb.com> [Sat, 12 Mar 2016 18:19:27 +0000] rev 1886
push: allow pushing new topic to non-publishing server by default This improves and fix the behavior change introduced by the new "topicmap". * Topics are properly ignored when pushing to a publishing server, * pushing new topics is allowed without --force a non-publishing server, * Pushing extra heads on a topic requires --force. Create of new head on a branch by phase movement is not properly detected for now. We'll improve that part in a later changesets. There is more awful monkey patching going on. We'll have to refactor core to get rid of them.
Sat, 12 Mar 2016 15:36:17 +0000 topic: take topic in account for all branch head computation
Pierre-Yves David <pierre-yves.david@fb.com> [Sat, 12 Mar 2016 15:36:17 +0000] rev 1885
topic: take topic in account for all branch head computation This changeset introduce a "topicmap" that is tracking not just the head of all branches, but the heads of all branch+topic pair. Including the head of the part of the branch without any topic. In practice this means that BRANCHNAME now resolve to the tipmost part for the branch without topic and impact various other logic like head checking during push and default destination for update and merge (these aspect will need adjustment in later changesets). The on-the-fly-temporary-monkey-patching process is pretty horrible, but allow to move forward without waiting on having core patched. We use 'branch:topic' as the branchmap key, this is a small and easy hack that help use a lot for (future) support of heads discovery/checking and on disc cache. I'm not sure it is worthwhile to improve this until an implementation into core. Note that this changeset change the branchmap in all cases, including during exchange, see next changeset for improved behavior. We also currently have the on-disk cache disabled because the core branchmap is lacking phase information in its cache key. This will get done in a later changesets
Mon, 14 Mar 2016 20:18:09 -0400 testedwith: declare compatibility with Mercurial 3.7
Augie Fackler <raf@durin42.com> [Mon, 14 Mar 2016 20:18:09 -0400] rev 1884
testedwith: declare compatibility with Mercurial 3.7
(0) -1000 -300 -100 -16 +16 +100 +300 +1000 +3000 tip