# HG changeset patch # User Pierre-Yves David # Date 1406752840 25200 # Node ID 58ff9d9c074611723a7e8417f22a19a711a4f3f1 # Parent a010ba5a0ffb58c9d6f3fb65762ee9863d938768# Parent 205d549a972fc9d0e16c8372619b0d6d118443b8 merge with stable diff -r 205d549a972f -r 58ff9d9c0746 README --- a/README Wed Jul 30 13:38:33 2014 -0700 +++ b/README Wed Jul 30 13:40:40 2014 -0700 @@ -29,9 +29,19 @@ ========== The simplest way to contribute is to issue a pull request on Bitbucket -(https://bitbucket.org/marmoute/mutable-history). Please don't forget -to update and run the tests when you fix a bug or add a feature. To -run the tests: +(https://bitbucket.org/marmoute/mutable-history). Alternatively, you +can use the patchbomb extension to send email to mercurial +devel. Please make sure to use the evolve-ext flag when doing so. You +can use a command like this: + + hg email --to mercurial-devel@selenic.com --flag evolve-ext --rev '' + +See also +http://mercurial.selenic.com/wiki/ContributingChanges#Patch_descriptions +for guidelines on the patch description. + +Please don't forget to update and run the tests when you fix a bug or +add a feature. To run the tests: cd tests python run-tests.py --with-hg=/path/to/hg @@ -47,6 +57,16 @@ Changelog ========= +4.1.0 -- + +- amend: add -D/--current-date option +- amend: add -U/--current-user option +- evolve: add a --tool option +- mark "commit -o", "graft -o" and "graft -O" as deprecated since they are + unlikely to eventually make it into core. +- push obsmarkers and phases in the same transaction than changesets + (when using hg >= 3.1 and bundle2-exp is enabled) + 4.0.0 -- 2014-06-03 - require Mercurial version 3.0.1 or above diff -r 205d549a972f -r 58ff9d9c0746 debian/rules --- a/debian/rules Wed Jul 30 13:38:33 2014 -0700 +++ b/debian/rules Wed Jul 30 13:40:40 2014 -0700 @@ -18,6 +18,7 @@ dh_python2 clean: clean-docs + rm -f tests/*.err clean-docs: rm -rf html diff -r 205d549a972f -r 58ff9d9c0746 docs/concepts.rst --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/docs/concepts.rst Wed Jul 30 13:40:40 2014 -0700 @@ -0,0 +1,223 @@ +.. Copyright 2014 Greg Ward + +---------------- +Evolve: Concepts +---------------- + +Getting the most out of software requires an accurate understanding of +the concepts underlying it. For example, you cannot use Mercurial to +its full potential without understanding the DAG (directed acyclic +graph) of changesets and the meaning of parent/child relationships +between nodes in that graph. Mercurial with changeset evolution adds +some additional concepts to the graph of changesets. Understanding +those concepts will make you an informed and empowered user of +``evolve``. + +.. note:: This document contains math! If you have a pathological fear + of set theory and the associated notation, you might be + better off just reading the `user guide`_. But if you + appreciate the theoretical rigour underlying core Mercurial, + you will be happy to know that it continues right into + changeset evolution. + +.. note:: This document is incomplete! (The formatting of the math + isn't quite right yet, and the diagrams are missing for + malformatted.) + +This document follows standard set theory notation: + + x ∈ A: x is a member of A + + A ∪ B: union of A and B: { x | x ∈ A or x ∈ B } + + A ∖ B: set difference: { x | x ∈ A and x ∉ B } + + A ⊇ B: superset: if x ∈ B, then x ∈ A + +.. _`user guide`: user-guide.html + +Phases +------ + +First, every changeset in a Mercurial repository (since 2.3) has a +*phase*. Phases are independent of ``evolve`` and they affect +Mercurial usage with or without changeset evolution. However, they +were implemented in order to support evolution, and are a critical +foundation of ``evolve``. + +Phases are strictly ordered: + + secret > draft > public + +Changesets generally only move from a higher phase to a lower phase. +Typically, changesets start life in *draft* phase, and move to +*public* phase when they are pushed to a public repository. (You can +set the default phase of new commits in Mercurial configuration.) + +The purpose of phases is to prevent modifying published history. +``evolve`` will therefore only let you rewrite changesets in one of +the two *mutable* phases (secret or draft). + +Run ``hg help phases`` for more information on phases. + +Obsolete changesets +------------------- + +*Obsolescence* is they key concept at the heart of changeset +evolution. Everything else in this document depends on understanding +obsolescence. So: what does it mean for a changeset to be obsolete? + +In implementation terms, there is an *obsolescence marker* associated +with changesets: every changeset is either obsolete or not. + +The simplest way that a changeset becomes obsolete is by *pruning* it. +The ``hg prune`` command simply marks the specified changesets +obsolete, as long as they are mutable. + +More commonly, a changeset *A* becomes obsolete by *amending* it. +Amendment creates a new changeset *A'* that replaces *A*, which is now +obsolete. *A'* is the successor of *A*, and *A* the predecessor of *A'*: + + [diagram: A and A' with pred/succ edge] + +The predecessor/successor relationship forms an additional +*obsolescence graph* overlaid on top of the traditional DAG formed by +changesets and their parent/child relationships. In fact, the +obsolescence graph is second-order version control. Where the +traditional parent/child DAG tracks changes to your source code, the +obsolescence graph tracks changes to your changesets. It tracks the +evolution of your changesets. + +(If you prefer a calculus metaphor to set theory, it might help to +think of the traditional parent/child DAG as the first derivative of +your source code, and the obsolescence DAG as the second derivative.) + +Troubled changesets (unstable, bumped, divergent) +------------------------------------------------- + +Evolving history can introduce problems that need to be solved. For +example, if you prune a changeset *P* but not its descendants, those +descendants are now on thin ice. To push a changeset to another +repository *R*, all of its ancestors must be present in *R* or pushed +at the same time. But Mercurial does not push obsolete changesets like +*P*, so it cannot push the descendants of *P*. Any non-obsolete +changeset that is a descendant of an obsolete changeset is said to be +*unstable*. + + [diagram: obsolete cset with non-obsolete descendant] + +Another sort of trouble occurs when two developers, Alice and Bob, +collaborate via a shared non-publishing repository. (This is how +developers can safely `share mutable history`_.) Say Alice and Bob +both start the day with changeset *C* in *draft* phase. If Alice +pushes *C* to their public repository, then it is now published and +therefore immutable. But Bob is working from a desert island and +cannot pull this change in *C*'s phase. For Bob, *C* is still in draft +phase and therefore mutable. So Bob amends *C*, which marks it +obsolete and replaces it with *C'*. When he is back online and pulls +from the public repository, Mercurial learns that *C* is public, which +means it cannot be obsolete. We say that *C'* is *bumped*, since it is +the successor of a public changeset. + +.. _`share mutable history`: sharing.html + +(Incidentally, the terminology here comes from airline overbooking: if +two people have bought tickets for the same seat on a plane and they +both show up at the airport, only one of them gets on the plane. The +passenger who is left behind in the airport terminal has been +"bumped".) + +The third sort of trouble is when Alice and Bob both amend the same +changeset *C* to have different successors. When this happens, the +successors are both called *divergent* (unless one of them is in +public phase; only mutable changesets are divergent). + +The collective term for unstable, bumped, and divergent changeset is +*troubled*: + + troubled = unstable ∪ bumped ∪ divergent + +It is possible for a changeset to be in any of the troubled categories +at the same time: it might be unstable and divergent, or bumped and +divergent, or whatever. + + [diagram: Venn diagram of troubled changesets, showing overlap] + +The presence of troubled changesets indicates the need to run ``hg +evolve``. + +Hidden (and visible) changesets +------------------------------- + +Some obsolete changesets are *hidden*: deliberately suppressed by +Mercurial and usually not visible through the UI. (As of Mercurial +2.9, there are still some commands that inadvertently reveal hidden +changesets; these are bugs and will be fixed in due course.) + +All hidden changesets are obsolete, and all obsolete changesets are +part of your repository. Mathematically speaking: + + repo ⊇ obsolete ⊇ hidden + +Or, putting it visually: + + [diagram: Venn diagram showing nested strict subsets] + +However, the presence of obsolete but not hidden changesets should be +temporary. The desired end state for any history mutation operation is +that all obsolete changesets are hidden, i.e.: + + repo ⊇ obsolete, obsolete = hidden + +Visually: + + [diagram: Venn diagram showing obsolete = hidden, subset of repo] + + +Why is this changeset visible? +------------------------------ + +Any changeset which is not hidden is *visible*. That is, + + visible = repo ∖ hidden + +(Recall that ∖ means set difference: *visible* is the set of +changesets that are in *repo* but not in *hidden*.) + +After amending or pruning a changeset, you might expect it to be +hidden. It doesn't always work out that way. The precise rules are: + + hideable = obsolete + blockers = bookmarks ∪ parents(workingcopy) ∪ localtags + hidden = hideable ∖ ancestors((repo ∖ hideable) ∪ blockers) + +This will probably be clearer with a worked example. First, here's a +repository with some obsolete changesets, some troubled changesets, +one bookmark, a working copy, and some hidden changesets: + + x-x + / + -o-o-o-o + \ + x-x-o + +Here's the computation required to determine which changesets are +hidden: + + repo = { 0, 1, 2, 3, 4, 5, 6, 7, 8 } + + hideable = obsolete = { 2, 4, 5, 8 } + + blockers = { 6 } ∪ { 4 } ∪ {} + + blockers = { 4, 6 } + + hidden = hideable ∖ ancestors((repo ∖ { 2, 4, 5, 8 }) ∪ { 4, 6 }) + + hidden = hideable ∖ ancestors({ 0, 1, 3, 6, 7 } ∪ { 4, 6 }) + + hidden = hideable ∖ ancestors({ 0, 1, 3, 4, 6, 7 }) + + hidden = { 2, 4, 5, 8 } ∖ { 0, 1, 2, 3, 4, 5, 6, 7 } + + hidden = { 8 } diff -r 205d549a972f -r 58ff9d9c0746 docs/conf.py --- a/docs/conf.py Wed Jul 30 13:38:33 2014 -0700 +++ b/docs/conf.py Wed Jul 30 13:40:40 2014 -0700 @@ -12,8 +12,8 @@ master_doc = 'index' # General substitutions. -project = 'Obsolete experimentation' -copyright = '2010-2011, pierre-yves.david@logilab.fr' +project = 'evolve extension for Mercurial' +copyright = '2010-2014, Pierre-Yves David, Greg Ward, and contributors' # The default replacements for |version| and |release|, also used in various # other places throughout the built documents. diff -r 205d549a972f -r 58ff9d9c0746 docs/figures/figure-ug01.svg --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/docs/figures/figure-ug01.svg Wed Jul 30 13:40:40 2014 -0700 @@ -0,0 +1,400 @@ + + + + diff -r 205d549a972f -r 58ff9d9c0746 docs/figures/figure-ug02.svg --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/docs/figures/figure-ug02.svg Wed Jul 30 13:40:40 2014 -0700 @@ -0,0 +1,590 @@ + + + + diff -r 205d549a972f -r 58ff9d9c0746 docs/figures/figure-ug03.svg --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/docs/figures/figure-ug03.svg Wed Jul 30 13:40:40 2014 -0700 @@ -0,0 +1,402 @@ + + + + diff -r 205d549a972f -r 58ff9d9c0746 docs/figures/figure-ug04.svg --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/docs/figures/figure-ug04.svg Wed Jul 30 13:40:40 2014 -0700 @@ -0,0 +1,547 @@ + + + + diff -r 205d549a972f -r 58ff9d9c0746 docs/figures/figure-ug05.svg --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/docs/figures/figure-ug05.svg Wed Jul 30 13:40:40 2014 -0700 @@ -0,0 +1,723 @@ + + + + diff -r 205d549a972f -r 58ff9d9c0746 docs/figures/figure-ug06.svg --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/docs/figures/figure-ug06.svg Wed Jul 30 13:40:40 2014 -0700 @@ -0,0 +1,851 @@ + + + + diff -r 205d549a972f -r 58ff9d9c0746 docs/figures/figure-ug07.svg --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/docs/figures/figure-ug07.svg Wed Jul 30 13:40:40 2014 -0700 @@ -0,0 +1,608 @@ + + + + diff -r 205d549a972f -r 58ff9d9c0746 docs/figures/figure-ug08.svg --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/docs/figures/figure-ug08.svg Wed Jul 30 13:40:40 2014 -0700 @@ -0,0 +1,415 @@ + + + + diff -r 205d549a972f -r 58ff9d9c0746 docs/figures/figure-ug09.svg --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/docs/figures/figure-ug09.svg Wed Jul 30 13:40:40 2014 -0700 @@ -0,0 +1,307 @@ + + + + diff -r 205d549a972f -r 58ff9d9c0746 docs/figures/figure-ug10.svg --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/docs/figures/figure-ug10.svg Wed Jul 30 13:40:40 2014 -0700 @@ -0,0 +1,872 @@ + + + + diff -r 205d549a972f -r 58ff9d9c0746 docs/figures/figure-ug11.svg --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/docs/figures/figure-ug11.svg Wed Jul 30 13:40:40 2014 -0700 @@ -0,0 +1,659 @@ + + + + diff -r 205d549a972f -r 58ff9d9c0746 docs/figures/figure-ug12.svg --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/docs/figures/figure-ug12.svg Wed Jul 30 13:40:40 2014 -0700 @@ -0,0 +1,606 @@ + + + + diff -r 205d549a972f -r 58ff9d9c0746 docs/index.rst --- a/docs/index.rst Wed Jul 30 13:38:33 2014 -0700 +++ b/docs/index.rst Wed Jul 30 13:40:40 2014 -0700 @@ -1,166 +1,105 @@ -.. Copyright 2011 Pierre-Yves David -.. Logilab SA - -======================================== -Changeset Evolution Experimentation -======================================== - +.. Copyright © 2014 Greg Ward -This is the online documentation of the `evolve extension`_. An experimental -extension that drive the implementation of the `changeset evolution concept`_ for -Mercurial. +================================== +Changeset Evolution with Mercurial +================================== -.. _`evolve extension`: http://mercurial.selenic.com/wiki/EvolveExtension -.. _`changeset evolution concept`: http://mercurial.selenic.com/wiki/ChangesetEvolution +`evolve`_ is an experimental Mercurial extension for safe mutable history. -Here are various materials on planned improvement to Mercurial regarding -rewriting history. +.. _`evolve`: http://mercurial.selenic.com/wiki/EvolveExtension -First, read about what challenges arise while rewriting history and how we plan to -solve them once and for all. - -.. toctree:: - :maxdepth: 2 - - instability - -The effort is split in two parts: +With core Mercurial, changesets are permanent and immutable. You can +commit new changesets to modify your source code, but you cannot +modify or remove old changesets—they are carved in stone for all +eternity. - * The **obsolescence marker** concept aims to provide an alternative to ``strip`` - to get rid of changesets. This concept has been partially implemented since - Mercurial 2.3. +For years, Mercurial has included various extensions that allow +history modification: ``rebase``, ``mq``, ``histedit``, and so forth. +These are useful and popular extensions, and in fact history +modification is one of the big reasons DVCSes (distributed version +control systems) like Mercurial took off. - * The **evolve** Mercurial extension rewrites history using obsolete - *marker* under the hood. - -The first and most important step is by far the **obsolescence marker**. However -most users will never be directly exposed to the concept. For this reason -this manual starts with changeset evolution. +But there's a catch: until now, Mercurial's various mechanisms for +modifying history have been *unsafe*, in that changesets were +destroyed (“stripped”) rather than simply made invisible. -Evolve: A robust alternative to MQ -==================================== - -Evolve is an experimental history rewriting extension that uses obsolete -markers. It is inspired by MQ and pbranch but has multiple advantages over -them: - -* Focus on your current work. +``evolve`` makes things better in a couple of ways: - You can focus your work on a single changeset and take care of adapting - descendent changesets later. - -* Handle **non-linear history with branches and merges** + * It changes the behaviour of most existing history modification + extensions (``rebase``, ``histedit``, etc.) so they use a safer + mechanism (*changeset obsolescence*, covered below) rather than + the older, less safe *strip* operation. -* Rely internally on Mercurial's **robust merge** mechanism. + * It provides a new way of modifying history that is roughly + equivalent to ``mq`` (but much nicer and safer). - Simple conflicts are handled by real merge tools using the appropriate ancestor. - Conflicts are much rarer and much more user friendly. +It helps to understand that ``evolve`` builds on infrastructure +already in core Mercurial: -* Mutable history **fully available all the time**. - - Always use 'hg update' and forget about (un)applying patches to access the - mutable part of your history. - - -* Use only **plain changesets** and forget about patches. Evolve will create and - exchange real changesets. Mutable history can be used in all usual operations: - pull, push, log, diff, etc. + * *Phases* (starting in Mercurial 2.1) allow you to distinguish + mutable and immutable changesets. We'll cover phases early in the + user guide, since understanding phases is essential to + understanding ``evolve``. -* Allow **sharing and collaboration** mutable history without fear of duplicates - (thanks to obsolete marker). - -* Cover all MQ usage but guard. - -.. warning:: The evolve extension and obsolete markers are at an experimental - stage. While using obsolete you willl likely be exposed to complex - implications of the **obsolete marker** concept. I do not recommend - non-power users to test this at this stage. + * *Changeset obsolescence* (starting in Mercurial 2.3) is how + Mercurial knows how history has been modified, specifically when + one changeset replaces another. In the obsolescence model, a + changeset is neither removed nor modified, but is instead marked + *obsolete* and typically replaced by a *successor*. Obsolete + changesets usually become *hidden* as well. Obsolescence is an + invisible feature until you start using ``evolve``, so we'll cover + it in the user guide too. - While numbered 1.0.0, the command line API of this version should - **not** be regarded as *stable*: command behavior, name and - options may change in future releases or once integrated into - Mercurial. It is still an immature extension; a lot of - features are still missing but there is low risk of - repository corruption. - - Production-ready version should hide such details from normal users. +Some of the things you can do with ``evolve`` are: -The evolve extension requires Mercurial 2.5 (older versions supports down to 2.2) - -To enable the evolve extension use:: - - $ hg clone https://bitbucket.org/marmoute/mutable-history -u stable - $ echo '[extensions]\nevolve=$PWD/mutable-history/hgext/evolve.py' >> ~/.hgrc - -You will probably want to use hgview_ to visualize obsolescence. Version 1.7.1 -or later is required. - -.. _hgview: http://www.logilab.org/project/hgview/ + * Fix a mistake immediately: “Oops! I just committed a changeset + with a syntax error—I'll fix that and amend the changeset so no + one sees my mistake.” (While this is possible using existing + features of core Mercurial, ``evolve`` makes it safer.) - - --- - -For more information see the documents below: - -.. toctree:: - :maxdepth: 1 + * Fix a mistake a little bit later: “Oops! I broke the tests three + commits back, but only noticed it now—I'll just update back to the + bad changeset, fix my mistake, amend the changeset, and evolve + history to update the affected changesets.” - tutorials/tutorial - evolve-good-practice - evolve-faq - from-mq - evolve-collaboration - qsync + * Remove unwanted changes: “I hacked in some debug output two + commits back; everything is working now, so I'll just prune that + unwanted changeset and evolve history before pushing.” -Smart changeset deletion: Obsolete Marker -========================================== - -The obsolete marker is a powerful concept that allows Mercurial to safely handle -history rewriting operations. It is a new type of relation between Mercurial -changesets that tracks the result of history rewriting operations. + * Share mutable history with yourself: say you do most of your + programming work locally, but need to test on a big remote server + somewhere before you know everything is good. You can use + ``evolve`` to share mutable history between two computers, pushing + finely polished changesets to a public repository only after + testing on the test server. -This concept is simple to define and provides a very solid base for: - -- very fast history rewriting operations - -- auditable and reversible history rewriting process - -- clean final history - -- share and collaborate on mutable parts of the history + * Share mutable history for code review: you don't want to publish + unreviewed changesets, but you can't block every commit waiting + for code review. The solution is to share mutable history with + your reviewer, amending each changeset until it passes review. -- gracefully handle history rewriting conflicts - -- allow various history rewriting UI to collaborate with a underlying common API +``evolve`` is experimental! +--------------------------- - --- +TODO -For more information, see the documents below - -.. toctree:: - :maxdepth: 1 + * unstable UI + * some corner cases not covered yet - obs-concept - obs-terms - obs-implementation - +Installation and setup +---------------------- -Known limitations and bugs -================================= - -Here is a list of known issues that will be fixed later: - +TODO -* You need to provide to `graft --continue -O` if you started you - graft using `-O`. - - you to manually specify target all the time. - -* Trying to exchange obsolete marker with a static http repo will crash. +Next steps: + * For a practical guide to using ``evolve`` in a single repository, + see the `user guide`_. + * For more advanced tricks, see `sharing mutable history`_. + * To learn about the concepts underlying ``evolve``, see `concepts`_ + (incomplete). + * If you're coming from MQ, see the `MQ migration guide`_ (incomplete). -* Extinct changesets are hidden using the *hidden* feature of mercurial only - supported by a few commands. - - Only ``hg log``, ``hgview`` and `hg glog` support it. Neither ``hg heads`` nor other visual viewers do. - -* hg heads shows extinct changesets. +.. _`user guide`: user-guide.html +.. _`concepts`: concepts.html +.. _`sharing mutable history`: sharing.html +.. _`MQ migration guide`: from-mq.html diff -r 205d549a972f -r 58ff9d9c0746 docs/sharing.rst --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/docs/sharing.rst Wed Jul 30 13:40:40 2014 -0700 @@ -0,0 +1,461 @@ +.. Copyright © 2014 Greg Ward + +------------------------------ +Evolve: Shared Mutable History +------------------------------ + +Once you have mastered the art of mutable history in a single +repository, you might want to move up to the next level: *shared* +mutable history. ``evolve`` lets you push and pull draft changesets +between repositories along with their obsolescence markers. This opens +up a number of interesting possibilities. + +The most common scenario is a single developer working across two +computers. Say you're working on code that must be tested on a remote +test server, probably in a rack somewhere, only accessible by SSH, and +running an “enterprise-grade” (out-of-date) OS. But you probably +prefer to write code locally: everything is setup the way you like it, +and you can use your preferred editor, IDE, merge/diff tools, etc. + +Traditionally, your options are limited: either + + * (ab)use your source control system by committing half-working code + in order to get it onto the remote test server, or + * go behind source control's back by using ``rsync`` (or similar) to + transfer your code back-and-forth until it is ready to commit + +The former is less bad with distributed version control systems like +Mercurial, but it's still far from ideal. (One important version +control “best practice” is that every commit should make things just a +little bit better, i.e. you should never commit code that is worse +than what came before.) The latter, avoiding version control entirely, +means that you're walking a tightrope without a safety net. One +accidental ``rsync`` in the wrong direction could destroy hours of +work. + +Using Mercurial with ``evolve`` to share mutable history solves all of +these problems. As with single-repository ``evolve``, you can commit +whenever the code is demonstrably better, even if all the tests aren't +passing yet—just ``hg amend`` when they are. And you can transfer +those half-baked changesets between repositories to try things out on +your test server before anything is carved in stone. + +A less common scenario is multiple developers sharing mutable history. +(This is in fact how Mercurial itself is developed.) We'll cover this +scenario later. But first, single-user sharing. + +Publishing and non-publishing repositories +------------------------------------------ + +The key to shared mutable history is to keep your changesets in +*draft* phase as you pass them around. Recall that by default, ``hg +push`` promotes changesets from *draft* to *public*, and public +changesets are immutable. You can change this behaviour by +reconfiguring the *target* repository so that it is non-publishing. +(Short version: set ``phases.publish`` to ``false``. Long version +follows.) + +Setting things up +----------------- + +We'll work an example with three local repositories, although in the +real world they'd most likely be on three different computers. First, +the public repository is where tested, polished changesets live, and +it is where you push/pull changesets to/from the rest of your team. :: + + $ hg init public + +We'll need two clones where work gets done:: + + $ hg clone -q public test-repo + $ hg clone -q test-repo dev-repo + +``dev-repo`` is your local machine, with GUI merge tools and IDEs and +everything configured just the way you like it. ``test-repo`` is the +test server in a rack somewhere behind SSH. So for the most part, +we'll develop in ``dev-repo``, push to ``test-repo``, test and polish +there, and push to ``public``. + +The key to making this whole thing work is to make ``test-repo`` +non-publishing:: + + $ cat >> test-repo/.hg/hgrc <> test-repo/.hg/hgrc <> dev-repo/.hg/hgrc < file1 + $ hg add file1 + $ hg commit -m 'create new project' + $ hg push -q + +and pull that into the development repository:: + + $ cd ../dev-repo + $ hg pull -u + +Amending a shared changeset +--------------------------- + +Everything you learned in the `user guide`_ applies to work done in +``dev-repo``. You can commit, amend, uncommit, evolve, and so forth +just as before. + +.. _`user guide`: user-guide.html + +Things get different when you push changesets to ``test-repo``. Or +rather, things stay the same, which *is* different: because we +configured ``test-repo`` to be non-publishing, draft changesets stay +draft when we push them to ``test-repo``. Importantly, they're also +draft (mutable) in ``test-repo``. + +Let's commit a preliminary change and push it to ``test-repo`` for +testing. :: + + $ echo 'fix fix fix' > file1 + $ hg commit -m 'prelim change' + $ hg push ../test-repo + +At this point, ``dev-repo`` and ``test-repo`` have the same changesets +in the same phases: + + [figure SG01: rev 0:0dc9 public, rev 1:f649 draft, same on both repos] + +(You may notice a change in notation from the user guide: now +changesets are labelled with their revision number and the first four +digits of the 40-digit hexadecimal changeset ID. Mercurial revision +numbers are never stable when working across repositories, especially +when obsolescence is involved. We'll see why shortly.) + +Now let's switch to ``test-repo`` to test our change:: + + $ cd ../test-repo + $ hg update + +Don't forget to ``hg update``! Pushing only adds changesets to a +remote repository; it does not update the working directory (unless +you have a hook that updates for you). + +Now let's imagine the tests failed because we didn't use proper +punctuation and capitalization (oops). Let's amend our preliminary fix +(and fix the lame commit message while we're at it):: + + $ echo 'Fix fix fix.' > file1 + $ hg amend -m 'fix bug 37' + +Now we're in a funny intermediate state (figure 2): revision 1:f649 is +obsolete in ``test-repo``, having been replaced by revision 3:60ff +(revision 2:2a03 is another one of those temporary amend commits that +we saw in the user guide)—but ``dev-repo`` knows nothing of these +recent developments. + + [figure SG02: rev 0:0dc9 public, rev 1:f649, 2:2a03 obsolete, rev 3:60ff draft -- but dev-repo same as in SG01] + +Let's resynchronize:: + + $ cd ../dev-repo + $ hg pull -u + +As seen in figure 3, this transfers the new changeset *and* the +obsolescence marker for revision 1. However, it does *not* transfer +the temporary amend commit, because it is obsolete. Push and pull +transfer obsolesence markers between repositories, but they do not +normally transfer obsolete changesets. + + [figure SG03: dev-repo grows new rev 2:60ff, marks 1:f649 obsolete] + +Because of this deliberately incomplete synchronization, revision +numbers in ``test-repo`` and ``dev-repo`` are no longer consistent. We +*must* use changeset IDs. + +Amend again, locally +-------------------- + +This process can repeat. Perhaps you figure out a more elegant fix to +the bug, and want to mutate history so nobody ever knows you had a +less-than-perfect idea. We'll implement it locally in ``dev-repo`` and +push to ``test-repo``:: + + $ echo 'Fix, fix, and fix.' > file1 + $ hg amend + $ hg push + +This time around, the temporary amend commit is in ``dev-repo``, and +it is not transferred to ``test-repo``—the same as before, just in the +opposite direction. Figure 4 shows the two repositories after amending +in ``dev-repo`` and pushing to ``test-repo``. + + [figure SG04: each repo has one temporary amend commit, but they're different in each one] + +Let's hop over to ``test-repo`` to test the more elegant fix:: + + $ cd ../test-repo + $ hg update -q + +This time, all the tests pass, so no further amendment is required. +This bug fix is finished, so we push it to the public repository:: + + $ hg push + [...] + added 1 changesets with 1 changes to 1 files + +Note that only one changeset—the final version, after two +amendments—was actually pushed. Again, Mercurial normally doesn't +transfer obsolete changesets on push and pull. (Specifically, it +doesn't transfer *hidden* changesets: roughly speaking, obsolete +changesets with no non-obsolete descendants. If you're curious, see +the `concept guide`_ for the precise definition of hidden.) + +.. _`concept guide`: concepts.html + +So the picture in ``public`` is much simpler than in either +``dev-repo`` or ``test-repo``. None of our missteps or amendments are +visible publicly, just the final, beautifully polished changeset: + + [figure SG05: public repo with rev 0:0dc9, 1:de61, both public] + +There is one important step left to do. Because we pushed from +``test-repo`` to ``public``, the pushed changeset is in *public* phase +in those two repositories. But ``dev-repo`` knows nothing of this: +that changeset is still *draft* there. If we're not careful, we might +mutate history in ``dev-repo``, obsoleting a changeset that is already +public. Let's avoid that situation for now by pulling from +``test-repo`` down to ``dev-repo``:: + + $ cd ../dev-repo + $ hg pull -u + +Getting into trouble +-------------------- + +Mercurial with ``evolve`` is a powerful tool, and using powerful tools +can have consequences. (You can cut yourself badly with a sharp knife, +but every competent chef keeps several around. Ever try to chop onions +with a spoon?) + +In the user guide, we saw examples of *unstable* changesets, which are +the most common type of troubled changeset. (Recall that a +non-obsolete changeset with obsolete ancestors is unstable.) + +Two other types of trouble can crop up: *bumped* and *divergent* +changesets. Both are more likely with shared mutable history, +especially mutable history shared by multiple developers. + +To demonstrate, let's start with the ``public`` repository as we left +it in the last example, with two immutable changesets (figure 5 +above). Two developers, Alice and Bob, start working from this point:: + + $ hg clone -q public alice + $ hg clone -q public bob + +We need to configure Alice's and Bob's working repositories similar to +``test-repo``, i.e. make them non-publishing and enable ``evolve``:: + + $ cat >> alice/.hg/hgrc < file2 + $ hg commit -q -A -m 'fix bug 15' + +Now Bob has a bad idea: he decides to pull whatever Alice is working +on and tweak her bug fix to his taste:: + + $ cd ../bob + $ hg pull -q -u ../alice + $ echo 'Fix.' > file2 + $ hg amend -q -A -m 'fix bug 15 (amended)' + +(Note the lack of communication between Alice and Bob. Failing to +communicate with your colleagues is a good way to get into trouble. +Nevertheless, ``evolve`` can usually sort things out, as we will see.) + + [figure SG06: Bob's repo with one amendment] + +After some testing, Alice realizes her bug fix is just fine as it is: +no need for further polishing and amending, this changeset is ready to +publish. :: + + $ cd ../alice + $ hg push -q + +This introduces a contradiction: in Bob's repository, changeset 2:e011 +(his copy of Alice's fix) is obsolete, since Bob amended it. But in +Alice's repository (and ``public``), that changeset is public: it is +immutable, carved in stone for all eternity. No changeset can be both +obsolete and public, so Bob is in for a surprise the next time he +pulls from ``public``:: + + $ cd ../bob + $ hg pull -q -u + 1 new bumped changesets + +Figure 7 shows what just happened to Bob's repository: changeset +2:e011 is now public, so it can't be obsolete. When that changeset was +obsolete, it made perfect sense for it to have a successor, namely +Bob's amendment of Alice's fix (changeset 4:fe88). But it's illogical +for a public changeset to have a successor, so 4:fe88 is in trouble: +it has been *bumped*. + + [figure SG07: 2:e011 now public not obsolete, 4:fe88 now bumped] + +As usual when there's trouble in your repository, the solution is to +evolve it:: + + $ hg evolve --all + +Figure 8 illustrate's Bob's repository after evolving away the bumped +changeset. Ignoring the obsolete changesets, Bob now has a nice, +clean, simple history. His amendment of Alice's bug fix lives on, as +changeset 5:227d—albeit with a software-generated commit message. (Bob +should probably amend that changeset to improve the commit message.) +But the important thing is that his repository no longer has any +troubled changesets, thanks to ``evolve``. + + [figure SG08: 5:227d is new, formerly bumped changeset 4:fe88 now hidden] + +Divergent changesets +-------------------- + +In addition to *unstable* and *bumped*, there is a third kind of +troubled changeset: *divergent*. When an obsolete changeset has two +successors, those successors are divergent. + +To illustrate, let's start Alice and Bob at the same +point—specifically, the point where Alice's repository currently +stands. Bob's repository is a bit of a mess, so we'll throw it away +and start him off with a copy of Alice's repository:: + + $ cd .. + $ rm -rf bob + $ cp -rp alice bob + +Now we'll have Bob commit a bug fix that could still be improved:: + + $ cd bob + $ echo 'pretty good fix' >> file1 + $ hg commit -u bob -m 'fix bug 24 (v1)' + +This time, Alice meddles with her colleague's work (still a bad +idea):: + + $ cd ../alice + $ hg pull -q -u ../bob + $ echo 'better (alice)' >> file1 + $ hg amend -u alice -m 'fix bug 24 (v2 by alice)' + +Here's where things change from the "bumped" scenario above: this +time, the original author (Bob) decides to amend his changeset too. :: + + $ cd ../bob + $ echo 'better (bob)' >> file1 + $ hg amend -u bob -m 'fix bug 24 (v2 by bob)' + +At this point, the divergence exists, but only in theory: Bob's +original changeset, 3:fe81, is obsolete and has two successors. But +those successors are in different repositories, so the trouble is not +visible to anyone yet. It will be as soon as one of our players pulls +from the other's repository. Let's make Bob the victim again:: + + $ hg pull -q -u ../alice + not updating: not a linear update + (merge or update --check to force update) + 2 new divergent changesets + +The “not a linear update” is our first hint that something is wrong, +but of course “2 new divergent changesets” is the real problem. Figure +9 shows both problems. + + [figure SG09: bob's repo with 2 heads for the 2 divergent changesets, 5:fc16 and 6:694f; wc is at 5:fc16, hence update refused; both are successors of obsolete 3:fe81, hence divergence] + +Now we need to get out of trouble. Unfortunately, a `bug`_ in +``evolve`` means that the usual answer (run ``hg evolve --all``) does +not work. Bob has to figure out the solution on his own: in this case, +merge. To avoid distractions, we'll set ``HGMERGE`` to make Mercurial +resolve any conflicts in favour of Bob. :: + + $ HGMERGE=internal:local hg merge + $ hg commit -m merge + +.. _`bug`: https://bitbucket.org/marmoute/mutable-history/issue/48/ + +This is approximately what ``hg evolve`` would do in this +circumstance, if not for that bug. One annoying difference is that +Mercurial thinks the two divergent changesets are still divergent, +which you can see with a simple revset query:: + + $ hg log -q -r 'divergent()' + 5:fc16901f4d7a + 6:694fd0f6b503 + +(That annoyance should go away when the bug is fixed.) + +Conclusion +---------- + +Mutable history is a powerful tool. Like a sharp knife, an experienced +user can do wonderful things with it, much more wonderful than with a +dull knife (never mind a rusty spoon). At the same time, an +inattentive or careless user can do harm to himself or others. +Mercurial with ``evolve`` goes to great lengths to limit the harm you +can do by trying to handle all possible types of “troubled” +changesets. But having a first-aid kit nearby does not excuse you from +being careful with sharp knives. + +Mutable history shared across multiple repositories by a single +developer is a natural extension of this model. Once you are used to +using a single sharp knife on its own, it's pretty straightforward to +chop onions and mushrooms using the same knife, or to alternate +between two chopping boards with different knives. + +Mutable history shared by multiple developers is a scary place to go. +Imagine a professional kitchen full of expert chefs tossing their +favourite knives back and forth, with the occasional axe or chainsaw +thrown in to spice things up. If you're confident that you *and your +colleagues* can do it without losing a limb, go for it. But be sure to +practice a lot first before you rely on it! diff -r 205d549a972f -r 58ff9d9c0746 docs/user-guide.rst --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/docs/user-guide.rst Wed Jul 30 13:40:40 2014 -0700 @@ -0,0 +1,561 @@ +.. Copyright © 2014 Greg Ward + +------------------ +Evolve: User Guide +------------------ + +.. contents:: + +Life without ``evolve`` +----------------------- + +Before we dive into learning about ``evolve``, let's look into some +features of core Mercurial that interact with ``evolve``. ``commit`` +affects ``evolve``, and ``evolve`` modifies how ``commit --amend`` +works. + +Example 1: Commit a new changeset +================================= + +To create a new changeset, simply run ``hg commit`` as usual. +``evolve`` does not change the behaviour of ``commit`` at all. + +However, it's important to understand that new changesets are in the +*draft* phase by default: they are mutable. This means that they can +be modified by Mercurial's existing history-editing commands +(``rebase``, ``histedit``, etc.), and also by the ``evolve`` +extension. Specifically, ``evolve`` adds a number of commands that can +be used to modify history: ``amend``, ``uncommit``, ``prune``, +``fold``, and ``evolve``. Generally speaking, changesets remain in +*draft* phase until they are pushed to another repository, at which +point they enter *public* phase. :: + + $ hg commit -m 'implement feature X' + $ hg phase -r . + 1: draft + +(Strictly speaking, changesets only become public when they are pushed +to a *publishing* repository. But all repositories are publishing by +default; you have to explicitly configure repositories to be +*non-publishing*. Non-publishing repositories are an advanced topic +which we'll see when we get to `sharing mutable history`_.) + +.. _`sharing mutable history`: sharing.html + +Example 2: Amend a changeset (traditional) +========================================== + +Imagine you've just committed a new changeset, and then you discover a +mistake. Maybe you forgot to run the tests and a failure slipped in. +You want to modify history so that you push one perfect changeset, +rather than one flawed changeset followed by an "oops" commit. (Or +perhaps you made a typo in the commit message—this is really feature +*Y*, not feature X. You can't fix that with a followup commit.) + +This is actually trivial with plain vanilla Mercurial since 2.2: fix +your mistake and run :: + + $ hg commit --amend -m 'implement feature Y' + +to create a new, amended changeset. The drawback of doing this with +vanilla Mercurial is that your original, flawed, changeset is removed +from the repository. This is *unsafe* history editing. It's probably +not too serious if all you did was fix a syntax error, but still. + +.. figure:: figures/figure-ug01.svg + + Figure 1: unsafe history modification with core Mercurial (not + using ``evolve``): the original revision 1 is destroyed. + +(Incidentally, Mercurial's traditional history modification mechanism +isn't *really* unsafe: any changeset(s) removed from the repository +are kept in a backup directory, so you can manually restore them later +if you change your mind. But it's awkward and inconvenient compared to +the features provided by ``evolve`` and changeset obsolescence.) + +Life with ``evolve`` (basic usage) +---------------------------------- + +Once you enable the ``evolve`` extension, a number of features are +available to you. First, we're going to explore several examples of +painless, trouble-free history modification. + +Example 3: Amend a changeset (with ``evolve``) +============================================== + +Outwardly, amending a changeset with ``evolve`` can look exactly the +same as it does with core Mercurial (example 2):: + + $ hg commit --amend -m 'implement feature Y' + +Alternately, you can use the new ``amend`` command added by +``evolve``:: + + $ hg amend -m 'implement feature Y' + +(``hg amend`` is nearly synonymous with ``hg commit --amend``. The +difference is that ``hg amend`` reuses the existing commit message by +default, whereas ``hg commit --amend`` runs your editor if you don't +pass ``-m`` or ``-l``.) + +Under the hood, though, things are quite different. Mercurial has +simply marked the old changeset *obsolete*, replacing it with a new +one. We'll explore what this means in detail later, after working +through a few more examples. + +Example 4: Prune an unwanted changeset +====================================== + +Sometimes you make a change, and then decide it was such a bad idea +that you don't want anyone to know about it. Or maybe it was a +debugging hack that you needed to keep around for a while, but do not +intend to ever push publicly. :: + + $ echo 'debug hack' >> file1.c + $ hg commit -m 'debug hack' + +In either case, ``hg prune`` is the answer. ``prune`` simply marks +changesets obsolete without creating any new changesets to replace +them:: + + $ hg prune . + 1 changesets pruned + 1 files updated, 0 files merged, 0 files removed, 0 files unresolved + working directory now at 934359450037 + +Outwardly, it appears that your “debug hack” commit never happened; +we're right back where we started:: + + $ hg parents --template '{rev}:{node|short} {desc|firstline}\n' + 3:934359450037 implement feature Y + +In reality, though, the “debug hack” is still there, obsolete and hidden. + +Example 5: Uncommit changes to certain files +============================================ + +Occasionally you commit more than you intended: perhaps you made +unrelated changes to different files, and thus intend to commit +different files separately. :: + + $ echo 'relevant' >> file1.c + $ echo 'irrelevant' >> file2.c + +If you forget to specify filenames on the ``commit`` command line, +Mercurial commits all those changes together:: + + $ hg commit -m 'fix bug 234' # oops: too many files + +Luckily, this mistake is easy to fix with ``uncommit``:: + + $ hg uncommit file2.c + $ hg status + M file2.c + +Let's verify that the replacement changeset looks right (i.e., +modifies only ``file1.c``):: + + $ hg parents --template '{rev}:{node|short} {desc|firstline}\n{files}\n' + 6:c8defeecf7a4 fix bug 234 + file1.c + +As before, the original flawed changeset is still there, but obsolete +and hidden. It won't be exchanged with other repositories by ``push``, +``pull``, or ``clone``. + +Example 6: Fold multiple changesets together into one +===================================================== + +If you're making extensive changes to fragile source code, you might +commit more frequently than normal so that you can fallback on a +known good state if one step goes badly. :: + + $ echo step1 >> file1.c + $ hg commit -m 'step 1' # revision 7 + $ echo step2 >> file1.c + $ hg commit -m 'step 2' # revision 8 + $ echo step3 >> file2.c + $ hg commit -m 'step 3' # revision 9 + +At the end of such a sequence, you often end up with a series of small +changesets that are tedious to review individually. It might make more +sense to combine them into a single changeset using the ``fold`` +command. + +To make sure we pass the right revisions to ``fold``, let's review the +changesets we just created, from revision 7:: + + $ hg log --template '{rev}:{node|short} {desc|firstline}\n' -r 7:: + 7:05e61aab8294 step 1 + 8:be6d5bc8e4cc step 2 + 9:35f432d9f7c1 step 3 + +and fold them:: + + $ hg fold -m 'fix bug 64' -r 7:: + 3 changesets folded + 1 files updated, 0 files merged, 0 files removed, 0 files unresolved + +This time, Mercurial marks three changesets obsolete, replacing them +all with a single *successor*. + +(You might be familiar with this operation under other names, like +*squash* or *collapse*.) + +Changeset obsolescence under the hood +------------------------------------- + +So far, everything has gone just fine. We haven't run into merge +conflicts or other trouble. Before we start exploring advanced usage +that can run into trouble, let's step back and see what happens when +Mercurial marks changesets obsolete. That will make it much easier to +understand the more advanced use cases we'll see later. + +When you have the ``evolve`` extension enabled, all history +modification uses the same underlying mechanism: the original +changesets are marked *obsolete* and replaced by zero or more +*successors*. The obsolete changesets are the *precursors* of their +successors. This applies equally to built-in commands (``commit +--amend``), commands added by ``evolve`` (``amend``, ``prune``, +``uncommit``, ``fold``), and even commands provided by other +extensions (``rebase``, ``histedit``). + +Another way of looking at it is that obsolescence is second-order +version control, i.e. the history of your history. We'll cover this in +more detail (and mathematical precision) in the `concepts`_ guide. + +.. _`concepts`: concepts.html + +Under the hood: Amend a changeset +================================= + +Consider Example 2, amending a changeset with ``evolve``. We saw above +that you can do this using the exact same command-line syntax as core +Mercurial, namely ``hg commit --amend``. But the implementation is +quite different, and Figure 2 shows how. + +.. figure:: figures/figure-ug02.svg + + Figure 2: safe history modification using ``evolve``: the original + revision 1 is preserved as an obsolete changeset. (The "temporary + amend commit", marked with T, is an implementation detail stemming + from limitations in Mercurial's current merge machinery. Future + versions of Mercurial will not create them.) + +In this case, the obsolete changesets are also *hidden*. That is the +usual end state for obsolete changesets. But many scenarios result in +obsolete changesets that are still visible, which indicates your +history modification work is not yet done. We'll see examples of that +later, when we cover advanced usage. + +Seeing hidden changesets +======================== + +TODO + +Under the hood: Prune an unwanted changeset +=========================================== + +``prune`` (example 4 above) is the simplest history modification +command provided by ``evolve``. All it does is mark the specified +changeset(s) obsolete, with no successor/precursor relationships +involved. (If the working directory parent was one of the obsolete +changesets, ``prune`` updates back to a suitable ancestor.) + +.. figure:: figures/figure-ug03.svg + + Figure 3: pruning a changeset marks it obsolete with no successors. + +Under the hood: Uncommit changes to certain files +================================================= + +In one sense, ``uncommit`` is a simplified version of ``amend``. Like +``amend``, it obsoletes one changeset and leaves it with a single +successor. Unlike ``amend``, there is no ugly "temporary amend commit" +cluttering up the repository. + +In another sense, ``uncommit`` is the inverse of ``amend``: ``amend`` +takes any uncommitted changes in the working dir and “adds” +them to the working directory's parent changeset. (In reality, of +course, it creates a successor changeset, marking the original +obsolete.) In contrast, ``uncommit`` takes some changes in the working +directory's parent and moves them to the working dir, creating a new +successor changeset in the process. Figure 4 illustrates. + +.. figure:: figures/figure-ug04.svg + + Figure 4: uncommit moves some of the changes from the working + directory parent into the working dir, preserving the remaining + changes as a new successor changeset. (N.B. revision 4 is not shown + here because it was marked obsolete in the previous example.) + + +Under the hood: Fold multiple changesets together into one +========================================================== + +The last basic example is folding multiple changesets into one, which +marks multiple changesets obsolete, replacing them all with a single +successor. + +.. figure:: figures/figure-ug05.svg + + Figure 5: fold combines multiple changesets into a single + successor, marking the original (folded) changesets obsolete. + + +Obsolete is not hidden +====================== + +TODO + + +Understanding revision numbers +============================== + +If you're trying these examples on your own, especially using ``hg +log`` without ``--hidden``, you have probably noticed some funny +business going on with revision numbers: there are now gaps in the +sequence. That's something you don't see with plain vanilla Mercurial; +normally, revision N is always followed by revision N+1. + +This is just the visible manifestation of hidden changesets. If +revision 95 is followed by revision 98, that means there are two +hidden changesets, 96 and 97, in between. + +Note that changeset IDs are still the permanent, immutable identifier +for changesets. Revision numbers are, as ever, a handy shorthand that +work in your local repository, but cannot be used across repositories. +They also have the useful property of showing when there are hidden +changesets lurking under the covers, which is why this document uses +revision numbers. + + +Life with ``evolve`` (advanced usage) +------------------------------------- + +Now that you've got a solid understanding of how ``evolve`` works in +concert with changeset obsolescence, let's explore some more advanced +scenarios. All of these scenarios will involve *unstable* changesets, +which is an unavoidable consequence of obsolescence. What really sets +``evolve`` apart from other history modification mechanisms is the +fact that it recognizes troubles like unstable changesets and provides +a consistent way for you to get out of trouble. + +(Incidentally, there are two other types of trouble that changesets +can get into with ``evolve``: they may be *divergent* or *bumped*. +Both of those states are more likely to occur when `sharing mutable +history`_, so we won't see them in this user guide.) + +.. _`sharing mutable history`: sharing.html + + +Example 7: Amend an older changeset +=================================== + +Sometimes you don't notice your mistakes until after you have +committed some new changesets on top of them. :: + + $ hg commit -m 'fix bug 17' # rev 11 (mistake here) + $ hg commit -m 'cleanup' # rev 12 + $ hg commit -m 'feature 23' # rev 13 + +Traditionally, your only option is to commit an "oops" changeset that +fixes your mistake. That works, of course, but it makes you look bad: +you made a mistake, and the record of that mistake is recorded in +history for all eternity. (If the mistake was in the commit message, +too bad.) + +More subtly, there now exist changesets that are *worse* than what +came before—the code no longer builds, the tests don't pass, or +similar. Anyone reviewing these patches will waste time noticing the +error in the earlier patch, and then the correction later on. + +You can avoid all this by amending the bad changeset and *evolving* +subsequent history. Here's how it works, assuming you have just +committed revision 13 and noticed the mistake in revision 11:: + + $ hg update 11 + [...fix mistake...] + $ hg amend + +At this point, revision 11 is *obsolete* and revisions 12 and 13—the +descendants of 11—are in a funny state: they are *unstable*. + +.. figure:: figures/figure-ug06.svg + + Figure 6: amending a changeset with descendants means the amended + changeset is obsolete but remains visible; its non-obsolete + descendants are *unstable*. The temporary amend commit, revision + 14, is hidden because it has no non-obsolete descendants. + +All non-obsolete descendants of an obsolete changeset are unstable. An +interesting consequence of this is that revision 11 is still visible, +even though it is obsolete. Obsolete changesets with non-obsolete +descendants are not hidden. + +The fix is to *evolve* history:: + + $ hg evolve --all + +This is a separate step, not automatically part of ``hg amend``, +because there might be conflicts. If your amended changeset modifies a +file that one of its descendants also modified, Mercurial has to fire +up your merge tool to resolve the conflict. More importantly, you have +to switch contexts from "writing code" to "resolving conflicts". That +can be an expensive context switch, so Mercurial lets you decide when +to do it. + +The end state, after ``evolve`` finishes, is that the original +revisions (11-13) are obsolete and hidden. Their successor revisions +(15-17) replace them. + +.. figure:: figures/figure-ug07.svg + + Figure 7: evolve your repository (``hg evolve --all``) to take care + of instability. Unstable changesets become obsolete, and are + replaced by successors just like the amended changeset was. + +Example 8: Prune an older changeset +=================================== + +Let's say you've just committed the following changesets:: + + $ hg commit -m 'useful work' # rev 18 + $ hg commit -m 'debug hack' # rev 19 + $ hg commit -m 'more work' # rev 20 + +You want to drop revision 19, but keep 18 and 20. No problem:: + + $ hg prune 19 + 1 changesets pruned + 1 new unstable changesets + +As above, this leaves your repository in a funny intermediate state: +revision 20 is the non-obsolete descendant of obsolete revision 19. +That is, revision 20 is unstable. + +.. figure:: figures/figure-ug08.svg + + Figure 8: ``hg prune`` marks a changeset obsolete without creating + a successor. Just like with ``hg amend``, non-obsolete descendants + of the pruned changeset are now unstable. + +As before, the solution to unstable changesets is to evolve your +repository:: + + $ hg evolve --all + +This rebases revision 20 on top of 18 as the new revision 21, leaving +19 and 20 obsolete and hidden: + +.. figure:: figures/figure-ug09.svg + + Figure 9: once again, ``hg evolve --all`` takes care of instability. + +Example 9: Uncommit files from an older changeset (discard changes) +======================================================================= + +As in example 5, let's say you accidentally commit some unrelated +changes together. Unlike example 5, you don't notice your mistake +immediately, but commit a new changeset on top of the bad one. :: + + $ echo 'this fixes bug 53' >> file1.c + $ echo 'debug hack' >> file2.c + $ hg commit -m 'fix bug 53' # rev 22 (oops) + $ echo 'and this handles bug 67' >> file1.c + $ hg commit -m 'fix bug 67' # rev 23 (fine) + +As with ``amend``, you need to travel back in time and repair revision +22, leaving your changes to ``file2.c`` back in the working +directory:: + + $ hg update 22 + 1 files updated, 0 files merged, 0 files removed, 0 files unresolved + $ hg uncommit file2.c + 1 new unstable changesets + $ hg status + M file2.c + +Now your repository has unstable changesets, so you need to evolve it. +But ``hg evolve`` requires a clean working directory to resolve merge +conflicts, so you need to decide what to do with ``file2.c``. + +In this case, the change to ``file2.c`` was a temporary debugging +hack, so we can discard it and immediately evolve the instability away:: + + $ hg revert file2.c + $ hg evolve --all + move:[23] fix bug 67 + atop:[24] fix bug 53 + +Figure 10 illustrates the whole process. + +.. figure:: figures/figure-ug10.svg + + Figure 10: ``hg uncommit`` of a changeset with descendants results + in instability *and* a dirty working directory, both of which must + be dealt with. + + +Example 10: Uncommit files to an older changeset (keep changes) +=================================================================== + +This is very similar to example 9. The difference that this time, our +change to ``file2.c`` is valuable enough to commit, making things a +bit more complicated. The setup is nearly identical:: + + $ echo 'fix a bug' >> file1.c + $ echo 'useful but unrelated' >> file2.c + $ hg commit -u dan -d '11 0' -m 'fix a bug' # rev 26 (oops) + $ echo 'new feature' >> file1.c + $ hg commit -u dan -d '12 0' -m 'new feature' # rev 27 (fine) + +As before, we update back to the flawed changeset (this time, +revision 26) and ``uncommit``, leaving uncommitted changes to +``file2.c`` in the working dir:: + + $ hg update -q 26 + 1 files updated, 0 files merged, 0 files removed, 0 files unresolved + $ hg uncommit -q file2.c # obsoletes rev 26, creates rev 28 + 1 new unstable changesets + $ hg status + M file2.c + +This time, let's save that useful change before evolving:: + + $ hg commit -m 'useful tweak' # rev 29 + +Figure 11 shows the story so far: ``uncommit`` obsoleted revision 26 +and created revision 28, the successor of 26. Then we committed +revision 29, a child of 28. We still have to deal with the unstable +revision 27. + +.. figure:: figures/figure-ug11.svg + + Figure 11: Uncommitting a file and then committing that change + separately will soon result in a two-headed repository. + +This is where things get tricky. As usual when a repository has +unstable changesets, we want to evolve it:: + + $ hg evolve --all + +The problem is that ``hg evolve`` rebases revision 27 onto revision +28, creating 30 (the successor of 27). This is entirely logical: 27 +was the child of 26, and 26's successor is 28. So of course 27's +successor (30) should be the child of 26's successor (28). +Unfortunately, that leaves us with a two-headed repository: + +.. figure:: figures/figure-ug12.svg + + Figure 12: ``evolve`` takes care of unstable changesets; it does + not solve all the world's problems. + +As usual when faced with a two-headed repository, you can either merge +or rebase. It's up to you. + + +Example 11: Recover an obsolete changeset +========================================= + +TODO diff -r 205d549a972f -r 58ff9d9c0746 hgext/drophack.py --- a/hgext/drophack.py Wed Jul 30 13:38:33 2014 -0700 +++ b/hgext/drophack.py Wed Jul 30 13:40:40 2014 -0700 @@ -106,7 +106,7 @@ # lock from the beginning to prevent race wlock = lock = None try: - lock = repo.wlock() + wlock = repo.wlock() lock = repo.lock() # check they have no children if repo.revs('%ld and public()', revs): diff -r 205d549a972f -r 58ff9d9c0746 hgext/evolve.py --- a/hgext/evolve.py Wed Jul 30 13:38:33 2014 -0700 +++ b/hgext/evolve.py Wed Jul 30 13:40:40 2014 -0700 @@ -19,7 +19,7 @@ - improves some aspect of the early implementation in Mercurial core ''' -testedwith = '3.0.1' +testedwith = '3.0.1 3.1' buglink = 'http://bz.selenic.com/' import sys @@ -58,11 +58,12 @@ from mercurial import node from mercurial import phases from mercurial import patch +from mercurial import pushkey from mercurial import revset from mercurial import scmutil from mercurial import templatekw from mercurial.i18n import _ -from mercurial.commands import walkopts, commitopts, commitopts2 +from mercurial.commands import walkopts, commitopts, commitopts2, mergetoolopts from mercurial.node import nullid from mercurial import wireproto from mercurial import localrepo @@ -325,6 +326,25 @@ ### experimental behavior ### ##################################################################### +commitopts3 = [ + ('D', 'current-date', None, + _('record the current date as commit date')), + ('U', 'current-user', None, + _('record the current user as committer')), +] + +def _resolveoptions(ui, opts): + """modify commit options dict to handle related options + + For now, all it does is figure out the commit date: respect -D unless + -d was supplied. + """ + # N.B. this is extremely similar to setupheaderopts() in mq.py + if not opts.get('date') and opts.get('current_date'): + opts['date'] = '%d %d' % util.makedate() + if not opts.get('user') and opts.get('current_user'): + opts['user'] = ui.username() + @eh.wrapfunction(mercurial.obsolete, 'createmarkers') def _createmarkers(orig, repo, relations, *args, **kwargs): """register parent information at prune time""" @@ -435,7 +455,7 @@ """``troubled()`` Changesets with troubles. """ - _ = revset.getargs(x, 0, 0, 'troubled takes no arguments') + revset.getargs(x, 0, 0, 'troubled takes no arguments') return repo.revs('%ld and (unstable() + bumped() + divergent())', subset) @@ -594,6 +614,13 @@ return 'unstable' return 'stable' +@eh.templatekw('troubles') +def showtroubles(repo, ctx, **args): + """:troubles: List of strings. Evolution troubles affecting the changeset + (zero or more of "unstable", "divergent" or "bumped").""" + return templatekw.showlist('trouble', ctx.troubles(), plural='troubles', + **args) + ##################################################################### ### Various trouble warning ### ##################################################################### @@ -1126,7 +1153,8 @@ 'do not perform actions, just print what would be done'), ('A', 'any', False, 'evolve any troubled changeset'), ('a', 'all', False, 'evolve all troubled changesets'), - ('c', 'continue', False, 'continue an interrupted evolution'), ], + ('c', 'continue', False, 'continue an interrupted evolution'), + ] + mergetoolopts, _('[OPTIONS]...')) def evolve(ui, repo, **opts): """Solve trouble in your repository @@ -1156,6 +1184,7 @@ anyopt = opts['any'] allopt = opts['all'] dryrunopt = opts['dry_run'] + ui.setconfig('ui', 'forcemerge', opts.get('tool', ''), 'evolve') if contopt: if anyopt: @@ -1322,11 +1351,10 @@ target = targets[0] displayer = cmdutil.show_changeset(ui, repo, {'template': shorttemplate}) target = repo[target] - repo.ui.status(_('move:')) if not ui.quiet: + repo.ui.status(_('move:')) displayer.show(orig) - repo.ui.status(_('atop:')) - if not ui.quiet: + repo.ui.status(_('atop:')) displayer.show(target) if progresscb: progresscb() todo = 'hg rebase -r %s -d %s\n' % (orig, target) @@ -1796,7 +1824,7 @@ ('', 'close-branch', None, _('mark a branch as closed, hiding it from the branch list')), ('s', 'secret', None, _('use the secret phase for committing')), - ] + walkopts + commitopts + commitopts2, + ] + walkopts + commitopts + commitopts2 + commitopts3, _('[OPTION]... [FILE]...')) def amend(ui, repo, *pats, **opts): """combine a changeset with updates and replace it with a new one @@ -1821,6 +1849,7 @@ opts['amend'] = True if not (edit or opts['message']): opts['message'] = repo['.'].description() + _resolveoptions(ui, opts) _alias, commitcmd = cmdutil.findcmd('commit', commands.table) return commitcmd[0](ui, repo, *pats, **opts) @@ -1946,7 +1975,8 @@ match = scmutil.match(old, pats, opts) newid = _commitfiltered(repo, old, match) if newid is None: - raise util.Abort(_('nothing to uncommit')) + raise util.Abort(_('nothing to uncommit'), + hint=_("use --all to uncommit all files")) # Move local changes on filtered changeset createmarkers(repo, [(old, (repo[newid],))]) phases.retractboundary(repo, oldphase, [newid]) @@ -2029,9 +2059,9 @@ p2 = ctx.p2().node() p1 = newmapping.get(p1, p1) p2 = newmapping.get(p2, p2) - new, _ = rewrite(repo, ctx, [], ctx, - [p1, p2], - commitopts={'extra': extra}) + new, unusedvariable = rewrite(repo, ctx, [], ctx, + [p1, p2], + commitopts={'extra': extra}) # store touched version to help potential children newmapping[ctx.node()] = new if not duplicate: @@ -2046,41 +2076,76 @@ lockmod.release(lock, wlock) @command('^fold|squash', - [('r', 'rev', [], _("explicitly specify the full set of revision to fold")), + [('r', 'rev', [], _("revision to fold")), + ('', 'exact', None, _("only fold specified revisions")) ] + commitopts + commitopts2, - # allow to choose the seed ? - _('rev')) + _('hg fold [OPTION]... [-r] REV')) def fold(ui, repo, *revs, **opts): - """Fold multiple revisions into a single one - - The revisions from your current working directory to the given one are folded - into a single successor revision. - - you can alternatively use --rev to explicitly specify revisions to be folded, - ignoring the current working directory parent. + """fold multiple revisions into a single one + + Folds a set of revisions with the parent of the working directory. + All revisions linearly between the given revisions and the parent + of the working directory will also be folded. + + Use --exact for folding only the specified revisions while ignoring the + parent of the working directory. In this case, the given revisions must + form a linear unbroken chain. + + .. container:: verbose + + Some examples: + + - Fold the current revision with its parent:: + + hg fold .^ + + - Fold all draft revisions with working directory parent:: + + hg fold 'draft()' + + See :hg:`help phases` for more about draft revisions and + :hg:`help revsets` for more about the `draft()` keyword + + - Fold revisions 3, 4, 5, and 6 with the working directory parent:: + + hg fold 3:6 + + - Only fold revisions linearly between foo and @:: + + hg fold foo::@ --exact """ revs = list(revs) - if revs: - if opts.get('rev', ()): - raise util.Abort("cannot specify both --rev and a target revision") - targets = scmutil.revrange(repo, revs) - revs = repo.revs('(%ld::.) or (.::%ld)', targets, targets) - elif 'rev' in opts: - revs = scmutil.revrange(repo, opts['rev']) - else: - revs = () + revs.extend(opts['rev']) if not revs: - ui.write_err('no revision to fold\n') + raise util.Abort(_('no revisions specified')) + + revs = scmutil.revrange(repo, revs) + + if not opts['exact']: + # Try to extend given revision starting from the working directory + extrevs = repo.revs('(%ld::.) or (.::%ld)', revs, revs) + discardedrevs = [r for r in revs if r not in extrevs] + if discardedrevs: + raise util.Abort(_("cannot fold non-linear revisions"), + hint=_("given revisions are unrelated to parent " + "of working directory")) + revs = extrevs + + if len(revs) == 1: + ui.write_err(_('single revision specified, nothing to fold\n')) return 1 + roots = repo.revs('roots(%ld)', revs) if len(roots) > 1: - raise util.Abort("set has multiple roots") + raise util.Abort(_("cannot fold non-linear revisions " + "(multiple roots given)")) root = repo[roots[0]] if root.phase() <= phases.public: - raise util.Abort("can't fold public revisions") + raise util.Abort(_("cannot fold public revisions")) heads = repo.revs('heads(%ld)', revs) if len(heads) > 1: - raise util.Abort("set has multiple heads") + raise util.Abort(_("cannot fold non-linear revisions " + "(multiple heads given)")) head = repo[heads[0]] wlock = lock = None try: @@ -2101,9 +2166,9 @@ commitopts['message'] = "\n".join(msgs) commitopts['edit'] = True - newid, _ = rewrite(repo, root, allctx, head, - [root.p1().node(), root.p2().node()], - commitopts=commitopts) + newid, unusedvariable = rewrite(repo, root, allctx, head, + [root.p1().node(), root.p2().node()], + commitopts=commitopts) phases.retractboundary(repo, targetphase, [newid]) createmarkers(repo, [(ctx, (repo[newid],)) for ctx in allctx]) @@ -2156,12 +2221,12 @@ entry = cmdutil.findcmd('commit', commands.table)[1] entry[1].append(('o', 'obsolete', [], - _("make commit obsolete this revision"))) + _("make commit obsolete this revision (DEPRECATED)"))) entry = cmdutil.findcmd('graft', commands.table)[1] entry[1].append(('o', 'obsolete', [], - _("make graft obsoletes this revision"))) + _("make graft obsoletes this revision (DEPRECATED)"))) entry[1].append(('O', 'old-obsolete', False, - _("make graft obsoletes its source"))) + _("make graft obsoletes its source (DEPRECATED)"))) ##################################################################### ### Obsolescence marker exchange experimenation ### @@ -2254,25 +2319,125 @@ yield d d = self.read(4096) - - -@eh.wrapfunction(exchange, '_pushobsolete') -def _pushobsolete(orig, pushop): - """utility function to push obsolete markers to a remote""" - pushop.ui.debug('try to push obsolete markers to remote\n') +bundle2partsgenerators = getattr(exchange, 'bundle2partsgenerators', None) + + +if bundle2partsgenerators is not None: + + def _pushb2phases(pushop, bundler): + """adds phases update to the main bundle2 push""" + outgoing = pushop.outgoing + unfi = pushop.repo.unfiltered() + remotephases = pushop.remote.listkeys('phases') + publishing = remotephases.get('publishing', False) + ana = phases.analyzeremotephases(pushop.repo, + outgoing.commonheads, + remotephases) + pheads, droots = ana + revset = 'heads((%ln::%ln))' + if not publishing: + revset += ' and public()' + # Get the list of all revs draft on remote by public here. + # XXX Beware that revset break if droots is not strictly + # XXX root we may want to ensure it is but it is costly + fallback = list(unfi.set(revset, droots, outgoing.commonheads)) + if not outgoing.missing: + future = fallback + else: + # adds changeset we are going to push as draft + # + # should not be necessary for pushblishing server, but because of + # an issue fixed in xxxxx we have to do it anyway. + fdroots = list(unfi.set('roots(%ln + %ln::)', outgoing.missing, droots)) + fdroots = [f.node() for f in fdroots] + future = list(unfi.set(revset, fdroots, outgoing.missingheads)) + + b2caps = bundle2.bundle2caps(pushop.remote) + if 'b2x:pushkey' not in b2caps: + return + pushop.stepsdone.add('phases') + part2node = [] + enc = pushkey.encode + for newremotehead in future: + part = bundler.newpart('b2x:pushkey') + part.addparam('namespace', enc('phases')) + part.addparam('key', enc(newremotehead.hex())) + part.addparam('old', enc(str(phases.draft))) + part.addparam('new', enc(str(phases.public))) + part2node.append((part.id, newremotehead)) + def handlereply(op): + for partid, pnode in part2node: + partrep = op.records.getreplies(partid) + results = partrep['pushkey'] + assert len(results) <= 1 + msg = None + if not results: + msg = _('server ignored update of %s to public!\n') % pnode + elif not int(results[0]['return']): + msg = _('updating %s to public failed!\n') % pnode + if msg is not None: + pushop.ui.warn(msg) + return handlereply + + def _pushb2obsmarker(pushop, bundler): + """adds obsmarker to the main bundle2 push""" + repo = pushop.repo + remote = pushop.remote + if ('obsmarkers' not in pushop.stepsdone + and (obsolete._enabled and repo.obsstore and + 'obsolete' in remote.listkeys('namespaces')) + and remote.capable('_evoext_b2x_obsmarkers_0')): + # + pushop.stepsdone.add('obsmarkers') + markers = _obsmarkersdiscovery(pushop) + if not markers: + repo.ui.status("OBSEXC: no marker to push\n") + repo.ui.status("OBSEXC: DONE\n") + return + obsdata = pushobsmarkerStringIO() + _encodemarkersstream(obsdata, markers) + obsdata.seek(0) + obsdata.ui = repo.ui + repo.ui.status("OBSEXC: pushing %i markers (%i bytes)\n" + % (len(markers), len(obsdata.getvalue()))) + bundler.newpart('EVOLVE:B2X:OBSMARKERV1', data=obsdata) + def callback(op): + repo.ui.progress('OBSEXC', None) + repo.ui.status("OBSEXC: DONE\n") + return callback + bundle2partsgenerators.append(_pushb2phases) + bundle2partsgenerators.append(_pushb2obsmarker) + + +def _obsmarkersdiscovery(pushop): + """return the list of marker that needs to be pushed to the server + + When used before (or at the same time) the changegroup have been pushed, it + returns the value as if the planned changegroup was succesful. Othewise it + use te actual common heads to decide whats needs to be pushed. + """ repo = pushop.repo remote = pushop.remote unfi = repo.unfiltered() cl = unfi.changelog + commonheads = pushop.commonheads + if commonheads is None: + if pushop.revs is None: + commonheads = pushop.outgoing.commonheads + sch = set(commonheads) + commonheads.extend(h for h in pushop.outgoing.missingheads + if h not in sch) + else: + commonheads = pushop.outgoing.missingheads if (obsolete._enabled and repo.obsstore and 'obsolete' in remote.listkeys('namespaces')): repo.ui.status("OBSEXC: computing relevant nodes\n") - revs = unfi.revs('::%ln', pushop.commonheads) + revs = unfi.revs('::%ln', commonheads) common = [] if remote.capable('_evoext_obshash_0'): repo.ui.status("OBSEXC: looking for common markers in %i nodes\n" % len(revs)) - common = findcommonobsmarkers(pushop.ui, repo, remote, revs) + common = findcommonobsmarkers(pushop.ui, unfi, remote, revs) revs = list(unfi.revs('%ld - (::%ln)', revs, common)) nodes = [cl.node(r) for r in revs] if nodes: @@ -2282,6 +2447,24 @@ else: repo.ui.status("OBSEXC: markers already in sync\n") markers = [] + return markers + +@eh.wrapfunction(exchange, '_pushobsolete') +def _pushobsolete(orig, pushop): + """utility function to push obsolete markers to a remote""" + stepsdone = getattr(pushop, 'stepsdone', None) + if stepsdone is not None: + if 'obsmarkers' in stepsdone: + return + stepsdone.add('obsmarkers') + pushop.ui.debug('try to push obsolete markers to remote\n') + repo = pushop.repo + remote = pushop.remote + unfi = repo.unfiltered() + cl = unfi.changelog + if (obsolete._enabled and repo.obsstore and + 'obsolete' in remote.listkeys('namespaces')): + markers = _obsmarkersdiscovery(pushop) if not markers: repo.ui.status("OBSEXC: no marker to push\n") elif remote.capable('_evoext_b2x_obsmarkers_0'): diff -r 205d549a972f -r 58ff9d9c0746 tests/_exc-util.sh --- a/tests/_exc-util.sh Wed Jul 30 13:38:33 2014 -0700 +++ b/tests/_exc-util.sh Wed Jul 30 13:40:40 2014 -0700 @@ -20,7 +20,7 @@ hg ci -m "$1" } getid() { - hg id --hidden --debug -ir "$1" + hg log --hidden --template '{node}\n' --rev "$1" } setuprepos() { diff -r 205d549a972f -r 58ff9d9c0746 tests/test-amend.t --- a/tests/test-amend.t Wed Jul 30 13:38:33 2014 -0700 +++ b/tests/test-amend.t Wed Jul 30 13:40:40 2014 -0700 @@ -1,6 +1,4 @@ $ cat >> $HGRCPATH < [defaults] - > amend=-d "0 0" > [extensions] > hgext.rebase= > hgext.graphlog= @@ -17,12 +15,12 @@ $ hg ci -Am adda adding a -Test amend captures branches +Test that amend captures branches $ hg branch foo marked working directory as branch foo (branches are permanent and global, did you want a bookmark?) - $ hg amend + $ hg amend -d '0 0' $ hg debugobsolete 07f4944404050f47db2e5c5071e0e84e7a27bba9 6a022cbb61d5ba0f03f98ff2d36319dfea1034ae 0 {'date': '* *', 'user': 'test'} (glob) b2e32ffb533cbe1d5759638c0cd4e8abc43b2738 0 {'date': '* *', 'user': 'test'} (glob) @@ -35,7 +33,7 @@ Test no-op - $ hg amend + $ hg amend -d '0 0' nothing changed [1] $ glog @@ -44,7 +42,7 @@ Test forcing the message to the same value, no intermediate revision. - $ hg amend -m 'adda' + $ hg amend -d '0 0' -m 'adda' nothing changed [1] $ glog @@ -80,4 +78,22 @@ | o 2@foo(draft) adda +Specify precise commit date with -d + $ hg amend -d '2001-02-03 04:05:06 +0700' + $ hg parents --template '{rev} {date|date}\n' + 5 Sat Feb 03 04:05:06 2001 +0700 +Specify "now" as commit date with -D + $ before=`date +%s` + $ hg amend -D + $ commit=`hg parents --template '{date|hgdate} rev{rev}\n'` + $ after=`date +%s` + $ (echo $before ; echo $commit; echo $after) | sort -k1 -n -s + \d+ (re) + \d+ 0 rev6 (re) + \d+ (re) + +Specify current user as committer with -U + $ HGUSER=newbie hg amend -U + $ hg parents --template '{rev} {author}\n' + 7 newbie diff -r 205d549a972f -r 58ff9d9c0746 tests/test-evolve.t --- a/tests/test-evolve.t Wed Jul 30 13:38:33 2014 -0700 +++ b/tests/test-evolve.t Wed Jul 30 13:40:40 2014 -0700 @@ -341,6 +341,27 @@ $ hg commit --amend -m 'dansk!' 2 new unstable changesets +(ninja test for the {trouble} template: + + $ hg log -G --template '{rev} {troubles}\n' + @ 13 + | + | o 11 unstable + | | + | o 10 unstable + | | + | x 9 + |/ + o 7 + | + o 6 + | + o 0 + + + +(/ninja) + $ hg evolve --all --traceback move:[10] dansk 2! atop:[13] dansk! @@ -518,6 +539,7 @@ 7:a5bfd90a2f29 stable $ echo 3 > 1 $ hg resolve -m 1 + (no more unresolved files) $ hg graft --continue -O grafting revision 7 $ glog --hidden @@ -592,26 +614,35 @@ $ rm *.orig $ hg fold - no revision to fold + abort: no revisions specified + [255] + $ hg fold . + single revision specified, nothing to fold [1] - $ hg fold 6 --rev 10 - abort: cannot specify both --rev and a target revision + $ hg fold 0::10 --rev 1 --exact + abort: cannot fold non-linear revisions (multiple heads given) + [255] + $ hg fold -r 4 -r 6 --exact + abort: cannot fold non-linear revisions (multiple roots given) [255] - $ hg fold 6 # want to run hg fold 6 - 2 changesets folded + $ hg fold 10 1 + abort: cannot fold non-linear revisions + (given revisions are unrelated to parent of working directory) + [255] + $ hg phase --public 0 + $ hg fold -r 0 + abort: cannot fold public revisions + [255] + $ hg fold -r 5 + 3 changesets folded 1 files updated, 0 files merged, 0 files removed, 0 files unresolved - $ glog - @ 11:dd4682c1a481@default(draft) add 1 - | - o 5:0b9e50c35132@default(draft) add 3 - | - o 4:ce341209337f@default(draft) add 4 - | - | o 1:73d38bb17fd7@default(draft) add 1 - |/ - o 0:8685c6d34325@default(draft) add 0 + $ hg fold 6 # want to run hg fold 6 + abort: unknown revision '6'! + [255] + $ hg log -r 11 --template '{desc}\n' + add 3 - $ hg log -r 11 --template '{desc}\n' + add 1 @@ -623,15 +654,15 @@ $ hg up 4 0 files updated, 0 files merged, 2 files removed, 0 files unresolved - $ hg fold --rev 4::11 --user victor - 3 changesets folded + $ hg fold --rev 4::11 --user victor --exact + 2 changesets folded 2 files updated, 0 files merged, 0 files removed, 0 files unresolved $ glog @ 12:d26d339c513f@default(draft) add 4 | | o 1:73d38bb17fd7@default(draft) add 1 |/ - o 0:8685c6d34325@default(draft) add 0 + o 0:8685c6d34325@default(public) add 0 $ hg log --template '{rev}: {author}\n' 12: victor @@ -655,8 +686,7 @@ $ hg olog 4 : add 4 - test - 5 : add 3 - test - 11 : add 1 - test + 11 : add 3 - test Test obsstore stat diff -r 205d549a972f -r 58ff9d9c0746 tests/test-exchange-A1.t --- a/tests/test-exchange-A1.t Wed Jul 30 13:38:33 2014 -0700 +++ b/tests/test-exchange-A1.t Wed Jul 30 13:40:40 2014 -0700 @@ -54,8 +54,8 @@ $ cp -r A.1.1 A.1.1.b -Variante a: push -r A ---------------------- +Variant a: push -r A +-------------------- $ dotest A.1.1.a A ## Running testcase A.1.1.a @@ -105,8 +105,8 @@ -Variante b: push ---------------------- +Variant b: push +--------------- $ dotest A.1.1.b ## Running testcase A.1.1.b @@ -213,8 +213,8 @@ $ cp -r A.1.2 A.1.2.b -Variante a: push -r A ---------------------- +Variant a: push -r A +-------------------- $ dotest A.1.2.a B ## Running testcase A.1.2.a @@ -261,8 +261,8 @@ # obstore: pulldest aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa f5bc6836db60e308a17ba08bf050154ba9c4fad7 0 {'date': '', 'user': 'test'} -Variante b: push ---------------------- +Variant b: push +--------------- $ dotest A.1.2.b ## Running testcase A.1.2.b diff -r 205d549a972f -r 58ff9d9c0746 tests/test-exchange-A3.t --- a/tests/test-exchange-A3.t Wed Jul 30 13:38:33 2014 -0700 +++ b/tests/test-exchange-A3.t Wed Jul 30 13:40:40 2014 -0700 @@ -73,8 +73,8 @@ $ cd .. $ cd .. -Actual Test for first version (changeset unknown remotly) ---------------------------------------------------------- +Actual Test for first version (changeset unknown in remote) +----------------------------------------------------------- $ dotest A.3.a A1 ## Running testcase A.3.a @@ -125,8 +125,8 @@ 28b51eb45704506b5c603decd6bf7ac5e0f6a52f e5ea8f9c73143125d36658e90ef70c6d2027a5b7 0 {'date': '', 'user': 'test'} -other variant: changeset know remotly -------------------------------------------- +other variant: changeset known in remote +---------------------------------------- $ setuprepos A.3.b creating test repo for test case A.3.b @@ -164,8 +164,8 @@ $ cd .. $ cd .. -Actual Test for first version (changeset unknown remotly) ---------------------------------------------------------- +Actual Test for first version (changeset unknown in remote) +----------------------------------------------------------- check it complains about multiple heads diff -r 205d549a972f -r 58ff9d9c0746 tests/test-exchange-A4.t --- a/tests/test-exchange-A4.t Wed Jul 30 13:38:33 2014 -0700 +++ b/tests/test-exchange-A4.t Wed Jul 30 13:40:40 2014 -0700 @@ -66,8 +66,8 @@ $ cd .. $ cd .. -Actual Test for first version (changeset unknown remotly) ---------------------------------------------------------- +Actual Test for first version (changeset unknown in remote) +----------------------------------------------------------- $ dotest A.4 B -f ## Running testcase A.4 diff -r 205d549a972f -r 58ff9d9c0746 tests/test-exchange-A5.t --- a/tests/test-exchange-A5.t Wed Jul 30 13:38:33 2014 -0700 +++ b/tests/test-exchange-A5.t Wed Jul 30 13:40:40 2014 -0700 @@ -54,7 +54,6 @@ $ hg debugobsolete aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa `getid 'desc(A0)'` $ hg debugobsolete `getid 'desc(B0)'` `getid 'desc(B1)'` $ hg debugobsolete `getid 'desc(A0)'` `getid 'desc(A1)'` - invalid branchheads cache (served): tip differs $ hg log -G --hidden @ 8c0a98c83722 (draft): A1 | diff -r 205d549a972f -r 58ff9d9c0746 tests/test-exchange-A6.t --- a/tests/test-exchange-A6.t Wed Jul 30 13:38:33 2014 -0700 +++ b/tests/test-exchange-A6.t Wed Jul 30 13:40:40 2014 -0700 @@ -42,7 +42,7 @@ $ mkcommit A1 created new head -make both changeset known remotly +make both changeset known in remote $ hg push -qf ../pushdest $ hg push -qf ../pulldest @@ -106,7 +106,7 @@ 28b51eb45704506b5c603decd6bf7ac5e0f6a52f e5ea8f9c73143125d36658e90ef70c6d2027a5b7 0 {'date': '', 'user': 'test'} Actual Test (bare push version) ------------------------------------ +------------------------------- $ dotest A.6.b ## Running testcase A.6.b diff -r 205d549a972f -r 58ff9d9c0746 tests/test-exchange-B1.t --- a/tests/test-exchange-B1.t Wed Jul 30 13:38:33 2014 -0700 +++ b/tests/test-exchange-B1.t Wed Jul 30 13:40:40 2014 -0700 @@ -3,7 +3,7 @@ $ . $TESTDIR/_exc-util.sh -=== B.1 Prune on non targeted common changeset === +=== B.1 Prune on non-targeted common changeset === .. {{{ .. ⊗ B @@ -53,7 +53,7 @@ $ cp -r B.1 B.1.a $ cp -r B.1 B.1.b -Actual Test (explicite push version) +Actual Test (explicit push version) ----------------------------------- $ dotest B.1.a A diff -r 205d549a972f -r 58ff9d9c0746 tests/test-exchange-B2.t --- a/tests/test-exchange-B2.t Wed Jul 30 13:38:33 2014 -0700 +++ b/tests/test-exchange-B2.t Wed Jul 30 13:40:40 2014 -0700 @@ -3,7 +3,7 @@ $ . $TESTDIR/_exc-util.sh -=== B.2 Pruned changeset on head. nothing pushed === +=== B.2 Pruned changeset on head: nothing pushed === .. {{{ .. ⊗ A @@ -48,7 +48,7 @@ $ cp -r B.2 B.2.a $ cp -r B.2 B.2.b -Actual Test (explicite push version) +Actual Test (explicit push version) ----------------------------------- $ dotest B.2.a O diff -r 205d549a972f -r 58ff9d9c0746 tests/test-exchange-B4.t --- a/tests/test-exchange-B4.t Wed Jul 30 13:38:33 2014 -0700 +++ b/tests/test-exchange-B4.t Wed Jul 30 13:40:40 2014 -0700 @@ -74,7 +74,7 @@ $ cp -r B.4 B.4.a $ cp -r B.4 B.4.b -Actual Test (explicite push version) +Actual Test (explicit push version) ----------------------------------- $ dotest B.4.a O diff -r 205d549a972f -r 58ff9d9c0746 tests/test-exchange-B5.t --- a/tests/test-exchange-B5.t Wed Jul 30 13:38:33 2014 -0700 +++ b/tests/test-exchange-B5.t Wed Jul 30 13:40:40 2014 -0700 @@ -72,8 +72,8 @@ $ cp -r B.5 B.5.a $ cp -r B.5 B.5.b -Actual Test (explicite push version) -------------------------------------- +Actual Test (explicit push version) +----------------------------------- $ dotest B.5.a B -f ## Running testcase B.5.a diff -r 205d549a972f -r 58ff9d9c0746 tests/test-exchange-B7.t --- a/tests/test-exchange-B7.t Wed Jul 30 13:38:33 2014 -0700 +++ b/tests/test-exchange-B7.t Wed Jul 30 13:40:40 2014 -0700 @@ -4,7 +4,7 @@ $ . $TESTDIR/_exc-util.sh -=== B.7 Prune on non targeted common changeset === +=== B.7 Prune on non-targeted common changeset === .. .. {{{ .. ⊗ B diff -r 205d549a972f -r 58ff9d9c0746 tests/test-exchange-C1.t --- a/tests/test-exchange-C1.t Wed Jul 30 13:38:33 2014 -0700 +++ b/tests/test-exchange-C1.t Wed Jul 30 13:40:40 2014 -0700 @@ -54,8 +54,8 @@ $ cp -r C.1 C.1.a $ cp -r C.1 C.1.b -Actual Test (explicite push) -------------------------------------- +Actual Test (explicit push) +--------------------------- $ dotest C.1.a O ## Running testcase C.1.a diff -r 205d549a972f -r 58ff9d9c0746 tests/test-exchange-C2.t --- a/tests/test-exchange-C2.t Wed Jul 30 13:38:33 2014 -0700 +++ b/tests/test-exchange-C2.t Wed Jul 30 13:40:40 2014 -0700 @@ -61,8 +61,8 @@ $ cp -r C.2 C.2.a $ cp -r C.2 C.2.b -Actual Test (explicite push) -------------------------------------- +Actual Test (explicit push) +--------------------------- $ dotest C.2.a A1 ## Running testcase C.2.a diff -r 205d549a972f -r 58ff9d9c0746 tests/test-exchange-C3.t --- a/tests/test-exchange-C3.t Wed Jul 30 13:38:33 2014 -0700 +++ b/tests/test-exchange-C3.t Wed Jul 30 13:40:40 2014 -0700 @@ -66,8 +66,8 @@ $ cp -r C.3 C.3.a $ cp -r C.3 C.3.b -Actual Test (explicite push) -------------------------------------- +Actual Test (explicit push) +--------------------------- $ dotest C.3.a O ## Running testcase C.3.a diff -r 205d549a972f -r 58ff9d9c0746 tests/test-exchange-C4.t --- a/tests/test-exchange-C4.t Wed Jul 30 13:38:33 2014 -0700 +++ b/tests/test-exchange-C4.t Wed Jul 30 13:40:40 2014 -0700 @@ -56,7 +56,6 @@ created new head $ hg debugobsolete --hidden `getid 'desc(A)'` `getid 'desc(B)'` $ hg debugobsolete --hidden `getid 'desc(A)'` `getid 'desc(C)'` - invalid branchheads cache (served): tip differs $ hg prune -qd '0 0' . $ hg log -G --hidden x 7f7f229b13a6 (draft): C diff -r 205d549a972f -r 58ff9d9c0746 tests/test-exchange-D1.t --- a/tests/test-exchange-D1.t Wed Jul 30 13:38:33 2014 -0700 +++ b/tests/test-exchange-D1.t Wed Jul 30 13:40:40 2014 -0700 @@ -3,7 +3,7 @@ $ . $TESTDIR/_exc-util.sh -=== D.1 Pruned changeset based on a missing precursors of something we miss === +=== D.1 Pruned changeset based on missing precursor of something not present === .. {{{ .. B ⊗ diff -r 205d549a972f -r 58ff9d9c0746 tests/test-exchange-D4.t --- a/tests/test-exchange-D4.t Wed Jul 30 13:38:33 2014 -0700 +++ b/tests/test-exchange-D4.t Wed Jul 30 13:40:40 2014 -0700 @@ -49,7 +49,6 @@ $ hg debugobsolete aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa `getid 'desc(A1)'` $ hg debugobsolete `getid 'desc(B0)'` bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb $ hg debugobsolete bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb `getid 'desc(B1)'` - invalid branchheads cache (served): tip differs $ hg log -G --hidden @ 069b05c3876d (draft): B1 | @@ -69,8 +68,8 @@ $ cd .. $ cd .. -Actual Test for first version (changeset unknown remotly) ---------------------------------------------------------- +Actual Test for first version (changeset unknown in remote) +----------------------------------------------------------- $ dotest A.3.a A1 ## Running testcase A.3.a diff -r 205d549a972f -r 58ff9d9c0746 tests/test-import.t --- a/tests/test-import.t Wed Jul 30 13:38:33 2014 -0700 +++ b/tests/test-import.t Wed Jul 30 13:40:40 2014 -0700 @@ -1,6 +1,6 @@ This feature requires mercurial 3.0 -(and the `only(` revset is 3.0 specific) +(and the `only()` revset is 3.0 specific) $ (hg help revset | grep '"only(' > /dev/null) || exit 80 diff -r 205d549a972f -r 58ff9d9c0746 tests/test-obsolete.t --- a/tests/test-obsolete.t Wed Jul 30 13:38:33 2014 -0700 +++ b/tests/test-obsolete.t Wed Jul 30 13:40:40 2014 -0700 @@ -65,7 +65,7 @@ 2 - 4538525df7e2 -Test that obsolete parent a properly computed +Test that obsolete precursors are properly computed $ qlog -r 'precursors(.)' --hidden 2 @@ -85,13 +85,13 @@ @@ -0,0 +1,1 @@ +obsol_c -Test that obsolete successors a properly computed +Test that obsolete successors are properly computed $ qlog -r 'successors(2)' --hidden 3 - 0d3f46688ccc -test obsolete changeset with no-obsolete descendant +test obsolete changeset with non-obsolete descendant $ hg up 1 -q $ mkcommit "obsol_c'" # 4 (on 1) created new head @@ -257,7 +257,7 @@ 2 - 0d3f46688ccc -Pushing again does not advertise extinct changeset +Pushing again does not advertise extinct changesets $ hg push ../other-new pushing to ../other-new @@ -299,9 +299,9 @@ 0 - 1f0dee641bb7 -pushing to stuff that doesn't support obsolete +pushing to stuff that doesn't support obsolescence -DISABLED. the _enable switch it global :-/ +DISABLED. the _enable switch is global :-/ .. $ hg init ../other-old .. > # XXX I don't like this but changeset get published otherwise @@ -464,7 +464,7 @@ 0 - 1f0dee641bb7 -Check that auto update ignore hidden changeset +Check that auto update ignores hidden changeset $ hg up 0 1 files updated, 0 files merged, 0 files removed, 0 files unresolved $ hg up @@ -472,7 +472,7 @@ $ hg id -n 8 -Check that named update do too +Check that named update does too $ hg update default 0 files updated, 0 files merged, 0 files removed, 0 files unresolved @@ -495,33 +495,36 @@ o 0 - 1f0dee641bb7 add a - $ hg log -G --template='{rev} - {node|short}\n' --hidden - x 9 - 83b5778897ad + $ hg log -G --template='{rev} - {node|short} {desc}\n' --hidden + x 9 - 83b5778897ad add toto - o 8 - 159dfc9fa5d3 + o 8 - 159dfc9fa5d3 add obsol_d'' | - | x 7 - 909a0fb57e5d + | x 7 - 909a0fb57e5d add obsol_d' |/ - | x 6 - 95de7fc6918d + | x 6 - 95de7fc6918d add obsol_d |/ - | x 5 - a7a6f2b5d8a5 + | x 5 - a7a6f2b5d8a5 add d |/ - | o 4 - 725c380fe99b + | o 4 - 725c380fe99b add obsol_c' | | - x | 3 - 0d3f46688ccc + x | 3 - 0d3f46688ccc add obsol_c |/ - | x 2 - 4538525df7e2 + | x 2 - 4538525df7e2 add c |/ - o 1 - 7c3bad9141dc + o 1 - 7c3bad9141dc add b | - o 0 - 1f0dee641bb7 + o 0 - 1f0dee641bb7 add a -should not rebase extinct changeset +should not rebase extinct changesets #excluded 'whole rebase set is extinct and ignored.' message not in core $ hg rebase -b '3' -d 4 --traceback 2 new divergent changesets + $ hg --hidden log -q -r 'successors(3)' + 4:725c380fe99b + 10:2033b4e49474 $ hg up tip ? files updated, 0 files merged, 0 files removed, 0 files unresolved (glob) $ hg log -G --template='{rev} - {node|short} {desc}\n' @@ -537,7 +540,7 @@ Does not complain about new head if you obsolete the old one -(re necesarry when we start runnind discovery on unfiltered repo in core) +(re necessary when we start running discovery on unfiltered repo in core) $ hg push ../other-new --traceback pushing to ../other-new diff -r 205d549a972f -r 58ff9d9c0746 tests/test-prev-next.t --- a/tests/test-prev-next.t Wed Jul 30 13:38:33 2014 -0700 +++ b/tests/test-prev-next.t Wed Jul 30 13:40:40 2014 -0700 @@ -48,6 +48,7 @@ no-move 2:4e26ef31f919 $ hg up 1 0 files updated, 0 files merged, 1 files removed, 0 files unresolved + (leaving bookmark mark) $ hg next 1 files updated, 0 files merged, 0 files removed, 0 files unresolved [2] added c diff -r 205d549a972f -r 58ff9d9c0746 tests/test-prune.t --- a/tests/test-prune.t Wed Jul 30 13:38:33 2014 -0700 +++ b/tests/test-prune.t Wed Jul 30 13:40:40 2014 -0700 @@ -41,11 +41,12 @@ $ hg prune --user blah --date '1979-12-15' . 1 changesets pruned 0 files updated, 0 files merged, 1 files removed, 0 files unresolved + (leaving bookmark BABAR) working directory now at 47d2a3944de8 $ hg debugobsolete 9d206ffc875e1bc304590549be293be36821e66c 0 {'date': '314064000 0', ('p1': '47d2a3944de8b013de3be9578e8e344ea2e6c097', )?'user': 'blah'} (re) -prune leaving unstability behind +prune leaving instability behind $ hg prune 1 1 changesets pruned @@ -236,6 +237,7 @@ $ hg bookmark -r 'c' 'delete' $ hg up -C todelete 0 files updated, 0 files merged, 0 files removed, 0 files unresolved + (activating bookmark todelete) $ hg prune -B nostrip bookmark 'nostrip' deleted abort: nothing to prune @@ -244,6 +246,7 @@ $ hg prune -B todelete 1 changesets pruned 0 files updated, 0 files merged, 0 files removed, 0 files unresolved + (leaving bookmark todelete) working directory now at d62d843c9a01 bookmark 'todelete' deleted $ hg id -ir dcbb326fdec2 diff -r 205d549a972f -r 58ff9d9c0746 tests/test-sharing.t --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/tests/test-sharing.t Wed Jul 30 13:40:40 2014 -0700 @@ -0,0 +1,314 @@ +Test script based on sharing.rst: ensure that all scenarios in that +document work as advertised. + +Setting things up + + $ cat >> $HGRCPATH < [alias] + > shortlog = log --template '{rev}:{node|short} {phase} {desc|firstline}\n' + > [extensions] + > rebase = + > EOF + $ echo "evolve=$(echo $(dirname $TESTDIR))/hgext/evolve.py" >> $HGRCPATH + $ hg init public + $ hg clone -q public test-repo + $ hg clone -q test-repo dev-repo + $ cat >> test-repo/.hg/hgrc < [phases] + > publish = false + > EOF + +To start things off, let's make one public, immutable changeset:: + + $ cd test-repo + $ echo 'my new project' > file1 + $ hg add file1 + $ hg commit -m'create new project' + $ hg push -q + +and pull that into the development repository:: + + $ cd ../dev-repo + $ hg pull -q -u + +Let's commit a preliminary change and push it to ``test-repo`` for +testing. :: + + $ echo 'fix fix fix' > file1 + $ hg commit -m'prelim change' + $ hg push -q ../test-repo + +Figure SG01 (roughly) + $ hg shortlog -G + @ 1:f6490818a721 draft prelim change + | + o 0:0dc9c9f6ab91 public create new project + +Now let's switch to test-repo to test our change and amend:: + $ cd ../test-repo + $ hg update -q + $ echo 'Fix fix fix.' > file1 + $ hg amend -m'fix bug 37' + +Figure SG02 + $ hg shortlog --hidden -G + @ 3:60ffde5765c5 draft fix bug 37 + | + | x 2:2a039763c0f4 draft temporary amend commit for f6490818a721 + | | + | x 1:f6490818a721 draft prelim change + |/ + o 0:0dc9c9f6ab91 public create new project + +Pull into dev-repo: obsolescence markers are transferred, but not +the new obsolete changeset. + $ cd ../dev-repo + $ hg pull -q -u + +Figure SG03 + $ hg shortlog --hidden -G + @ 2:60ffde5765c5 draft fix bug 37 + | + | x 1:f6490818a721 draft prelim change + |/ + o 0:0dc9c9f6ab91 public create new project + +Amend again in dev-repo + $ echo 'Fix, fix, and fix.' > file1 + $ hg amend + $ hg push -q + +Figure SG04 (dev-repo) + $ hg shortlog --hidden -G + @ 4:de6151c48e1c draft fix bug 37 + | + | x 3:ad19d3570adb draft temporary amend commit for 60ffde5765c5 + | | + | x 2:60ffde5765c5 draft fix bug 37 + |/ + | x 1:f6490818a721 draft prelim change + |/ + o 0:0dc9c9f6ab91 public create new project + +Figure SG04 (test-repo) + $ cd ../test-repo + $ hg update -q + $ hg shortlog --hidden -G + @ 4:de6151c48e1c draft fix bug 37 + | + | x 3:60ffde5765c5 draft fix bug 37 + |/ + | x 2:2a039763c0f4 draft temporary amend commit for f6490818a721 + | | + | x 1:f6490818a721 draft prelim change + |/ + o 0:0dc9c9f6ab91 public create new project + +This bug fix is finished. We can push it to the public repository. + $ hg push + pushing to $TESTTMP/public + searching for changes + adding changesets + adding manifests + adding file changes + added 1 changesets with 1 changes to 1 files + OBSEXC: computing relevant nodes + OBSEXC: computing markers relevant to 2 nodes + OBSEXC: pushing 4 markers (341 bytes) + OBSEXC: DONE + +Figure SG05 + $ hg -R ../public shortlog -G + o 1:de6151c48e1c public fix bug 37 + | + o 0:0dc9c9f6ab91 public create new project + +Oops, still have draft changesets in dev-repo. + $ cd ../dev-repo + $ hg shortlog -r 'draft()' + 4:de6151c48e1c draft fix bug 37 + $ hg pull -q -u + $ hg shortlog -r 'draft()' + +Sharing by Alice and Bob to demonstrate bumped and divergent changesets. +First, setup repos for them. + + $ cd .. + $ hg clone -q public alice + $ hg clone -q public bob + $ cat >> alice/.hg/hgrc < [phases] + > publish = false + > EOF + $ cp alice/.hg/hgrc bob/.hg/hgrc + +Alice commits a bug fix. + $ cd alice + $ echo 'fix' > file2 + $ hg commit -q -A -u alice -m 'fix bug 15' + +Bob pulls and amends Alice's fix. + $ cd ../bob + $ hg pull -q -u ../alice + $ echo 'Fix.' > file2 + $ hg amend -q -A -u bob -m 'fix bug 15 (amended)' + +Figure SG06: Bob's repository after amending Alice's fix. +(Nothing new here; we could have seen this in the user guide. + $ hg --hidden shortlog -G + @ 4:fe884dfac355 draft fix bug 15 (amended) + | + | x 3:0376cac226f8 draft temporary amend commit for e011baf925da + | | + | x 2:e011baf925da draft fix bug 15 + |/ + o 1:de6151c48e1c public fix bug 37 + | + o 0:0dc9c9f6ab91 public create new project + + +But in the meantime, Alice decides the fix is just fine and publishes it. + $ cd ../alice + $ hg push -q + +Which means that Bob now has an formerly obsolete changeset that is +also public (2:6e83). As soon as he pulls its phase change, he's got +trouble: the successors of that formerly obsolete changeset are +bumped. + + $ cd ../bob + $ hg --hidden shortlog -r 'obsolete()' + 2:e011baf925da draft fix bug 15 + 3:0376cac226f8 draft temporary amend commit for e011baf925da + $ hg pull -q -u + 1 new bumped changesets + $ hg --hidden shortlog -r 'obsolete()' + 3:0376cac226f8 draft temporary amend commit for e011baf925da + $ hg shortlog -r 'bumped()' + 4:fe884dfac355 draft fix bug 15 (amended) + +Figure SG07: Bob's repo with one bumped changeset (rev 4:c02d) + $ hg --hidden shortlog -G + @ 4:fe884dfac355 draft fix bug 15 (amended) + | + | x 3:0376cac226f8 draft temporary amend commit for e011baf925da + | | + | o 2:e011baf925da public fix bug 15 + |/ + o 1:de6151c48e1c public fix bug 37 + | + o 0:0dc9c9f6ab91 public create new project + + +Bob gets out of trouble by evolving the repository. + $ hg evolve --all + recreate:[4] fix bug 15 (amended) + atop:[2] fix bug 15 + computing new diff + committed as 227d860d9ad0 + +Figure SG08 + $ hg --hidden shortlog -G + @ 5:227d860d9ad0 draft bumped update to e011baf925da: + | + | x 4:fe884dfac355 draft fix bug 15 (amended) + | | + +---x 3:0376cac226f8 draft temporary amend commit for e011baf925da + | | + o | 2:e011baf925da public fix bug 15 + |/ + o 1:de6151c48e1c public fix bug 37 + | + o 0:0dc9c9f6ab91 public create new project + + +Throw away Bob's messy repo and start over. + $ cd .. + $ rm -rf bob + $ cp -rp alice bob + +Bob commits a pretty good fix that both he and Alice will amend, +leading to divergence. + $ cd bob + $ echo 'pretty good fix' >> file1 + $ hg commit -u bob -m 'fix bug 24 (v1)' + +Alice pulls Bob's fix and improves it. + $ cd ../alice + $ hg pull -q -u ../bob + $ echo 'better (alice)' >> file1 + $ hg amend -u alice -m 'fix bug 24 (v2 by alice)' + +Likewise, Bob amends his own fix. Now we have an obsolete changeset +with two successors, although the successors are in different repos. + $ cd ../bob + $ echo 'better (bob)' >> file1 + $ hg amend -u bob -m 'fix bug 24 (v2 by bob)' + +Bob pulls from Alice's repo and discovers the trouble: divergent changesets! + $ hg pull -q -u ../alice + not updating: not a linear update + (merge or update --check to force update) + 2 new divergent changesets + $ hg shortlog -r 'divergent()' + 5:fc16901f4d7a draft fix bug 24 (v2 by bob) + 6:694fd0f6b503 draft fix bug 24 (v2 by alice) + +Figure SG09 + $ hg --hidden shortlog -G + o 6:694fd0f6b503 draft fix bug 24 (v2 by alice) + | + | @ 5:fc16901f4d7a draft fix bug 24 (v2 by bob) + |/ + | x 4:162612d3335b draft temporary amend commit for fe81d904ed08 + | | + | x 3:fe81d904ed08 draft fix bug 24 (v1) + |/ + o 2:e011baf925da public fix bug 15 + | + o 1:de6151c48e1c public fix bug 37 + | + o 0:0dc9c9f6ab91 public create new project + +Merge the trouble away. + $ hg merge --tool internal:local + 0 files updated, 1 files merged, 0 files removed, 0 files unresolved + (branch merge, don't forget to commit) + $ hg commit -m merge + $ hg shortlog -G + @ 7:b1d30ba26e44 draft merge + |\ + | o 6:694fd0f6b503 draft fix bug 24 (v2 by alice) + | | + o | 5:fc16901f4d7a draft fix bug 24 (v2 by bob) + |/ + o 2:e011baf925da public fix bug 15 + | + o 1:de6151c48e1c public fix bug 37 + | + o 0:0dc9c9f6ab91 public create new project + + $ hg log -q -r 'divergent()' + 5:fc16901f4d7a + 6:694fd0f6b503 + +# XXX hg evolve does not solve this trouble! bug in evolve? +#Evolve the trouble away. +# $ hg evolve --all --tool=internal:local +# merge:[5] fix bug 24 (v2 by bob) +# with: [6] fix bug 24 (v2 by alice) +# base: [3] fix bug 24 (v1) +# 0 files updated, 1 files merged, 0 files removed, 0 files unresolved +# $ hg status +# $ hg shortlog -G +# o 6:694fd0f6b503 draft fix bug 24 (v2 by alice) +# | +# | @ 5:fc16901f4d7a draft fix bug 24 (v2 by bob) +# |/ +# o 2:e011baf925da public fix bug 15 +# | +# o 1:de6151c48e1c public fix bug 37 +# | +# o 0:0dc9c9f6ab91 public create new project +# +# $ hg --hidden shortlog -G diff -r 205d549a972f -r 58ff9d9c0746 tests/test-stabilize-conflict.t --- a/tests/test-stabilize-conflict.t Wed Jul 30 13:38:33 2014 -0700 +++ b/tests/test-stabilize-conflict.t Wed Jul 30 13:40:40 2014 -0700 @@ -1,6 +1,6 @@ -================================================================= -This files test the proper behavior of evo during merge conflict. -================================================================= +========================================================= +Test the proper behavior of evolve during merge conflict. +========================================================= Initial setup @@ -164,6 +164,7 @@ reverting babar $ safesed 's/dix/ten/' babar $ hg resolve --all -m + (no more unresolved files) $ hg evolve --continue grafting revision 5 $ hg resolve -l @@ -185,8 +186,8 @@ date: Thu Jan 01 00:00:00 1970 +0000 summary: babar count up to five -proper behavior with conflict using an external merge tools ------------------------------------------------------------ +proper behavior with conflict using an external merge tool +---------------------------------------------------------- $ safesed 's/merge=.*/merge=touch/' $HGRCPATH $ safesed 's/touch.gui=.*/touch.gui=false/' $HGRCPATH @@ -208,7 +209,7 @@ $ hg amend 1 new unstable changesets $ safesed 's/interactive=.*/interactive=true/' $HGRCPATH - $ HGMERGE=touch hg evolve < n > EOF move:[8] babar count up to fifteen diff -r 205d549a972f -r 58ff9d9c0746 tests/test-stabilize-order.t --- a/tests/test-stabilize-order.t Wed Jul 30 13:38:33 2014 -0700 +++ b/tests/test-stabilize-order.t Wed Jul 30 13:40:40 2014 -0700 @@ -85,7 +85,7 @@ o 0:c471ef929e6a@default(draft) addroot -Test stabilizing a descendant predecessors child +Test stabilizing a descendant predecessor's child $ hg up 7 0 files updated, 0 files merged, 1 files removed, 0 files unresolved diff -r 205d549a972f -r 58ff9d9c0746 tests/test-stabilize-result.t --- a/tests/test-stabilize-result.t Wed Jul 30 13:38:33 2014 -0700 +++ b/tests/test-stabilize-result.t Wed Jul 30 13:40:40 2014 -0700 @@ -25,6 +25,7 @@ $ hg bookmark changea $ hg up 1 1 files updated, 0 files merged, 0 files removed, 0 files unresolved + (leaving bookmark changea) $ echo a >> a $ hg amend -m changea 1 new unstable changesets @@ -94,13 +95,14 @@ abort: unresolved merge conflicts (see hg help resolve) [255] $ hg resolve -m a + (no more unresolved files) $ hg evolve --continue grafting revision 5 -Stabilize of late comer with different parent -================================================== +Stabilize latecomer with different parent +========================================= -(the same parent case is handled in test-evolve.t) +(the same-parent case is handled in test-evolve.t) $ glog @ 8:1cf0aacfd363@default(draft) bk:[] newer a @@ -146,7 +148,7 @@ o 0:07f494440405@default(public) bk:[] adda -Stabilize ! +Stabilize! $ hg evolve --any --dry-run recreate:[12] newer a @@ -173,8 +175,8 @@ o 0:07f494440405@default(public) bk:[] adda -Stabilize divergenent changesets with same parent -================================================= +Stabilize divergent changesets with same parent +=============================================== $ rm a.orig $ hg up 9 @@ -228,7 +230,7 @@ o 0:07f494440405@default(public) bk:[] adda -Stabilize It +Stabilize it $ hg evolve -qn --traceback hg update -c eacc9c8240fe && diff -r 205d549a972f -r 58ff9d9c0746 tests/test-tutorial.t --- a/tests/test-tutorial.t Wed Jul 30 13:38:33 2014 -0700 +++ b/tests/test-tutorial.t Wed Jul 30 13:40:40 2014 -0700 @@ -473,21 +473,24 @@ The tutorial part is not written yet but can use `hg fold`: $ hg help fold - hg fold rev + hg fold [OPTION]... [-r] REV aliases: squash - Fold multiple revisions into a single one + fold multiple revisions into a single one - The revisions from your current working directory to the given one are - folded into a single successor revision. + Folds a set of revisions with the parent of the working directory. All + revisions linearly between the given revisions and the parent of the + working directory will also be folded. - you can alternatively use --rev to explicitly specify revisions to be - folded, ignoring the current working directory parent. + Use --exact for folding only the specified revisions while ignoring the + parent of the working directory. In this case, the given revisions must + form a linear unbroken chain. options: - -r --rev VALUE [+] explicitly specify the full set of revision to fold + -r --rev VALUE [+] revision to fold + --exact only fold specified revisions -m --message TEXT use text as commit message -l --logfile FILE read commit message from file -d --date DATE record the specified date as commit date @@ -495,7 +498,7 @@ [+] marked option can be specified multiple times - use "hg -v help fold" to show the global options + use "hg -v help fold" to show more complete help and the global options ----------------------- diff -r 205d549a972f -r 58ff9d9c0746 tests/test-uncommit.t --- a/tests/test-uncommit.t Wed Jul 30 13:38:33 2014 -0700 +++ b/tests/test-uncommit.t Wed Jul 30 13:40:40 2014 -0700 @@ -152,6 +152,7 @@ $ hg uncommit abort: nothing to uncommit + (use --all to uncommit all files) [255] $ hg bookmarks * touncommit-bm 3:5eb72dbe0cb4 @@ -162,6 +163,7 @@ $ hg uncommit --include nothere abort: nothing to uncommit + (use --all to uncommit all files) [255] Enjoy uncommit @@ -238,6 +240,7 @@ $ hg up -C 3 --hidden 8 files updated, 0 files merged, 1 files removed, 0 files unresolved + (leaving bookmark touncommit-bm) working directory parent is obsolete! $ hg --config extensions.purge= purge $ hg uncommit -I 'set:added() and e' diff -r 205d549a972f -r 58ff9d9c0746 tests/test-userguide.t --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/tests/test-userguide.t Wed Jul 30 13:40:40 2014 -0700 @@ -0,0 +1,316 @@ +ensure that all the scenarios in the user guide work as documented + +basic repo + $ hg init t + $ cd t + $ touch file1.c file2.c + $ hg -q commit -A -m init + +example 1: commit creates a changeset in draft phase +(this is nothing to do with evolve, but it's mentioned in the user guide) + $ echo 'feature Y' >> file1.c + $ hg commit -u alice -d '0 0' -m 'implement feature X' + $ hg phase -r . + 1: draft + $ hg identify -in + 6e725fd2be6f 1 + +example 2: unsafe amend with plain vanilla Mercurial: the original +commit is stripped + $ hg commit --amend -u alice -d '1 0' -m 'implement feature Y' + saved backup bundle to $TESTTMP/t/.hg/strip-backup/6e725fd2be6f-amend-backup.hg + $ hg log -r 23fe4ac6d3f1 + abort: unknown revision '23fe4ac6d3f1'! + [255] + $ hg identify -in + fe0ecd3bd2a4 1 + +enable evolve for safe history modification + $ cat >> $HGRCPATH < [alias] + > shortlog = log --template '{rev}:{node|short} {phase} {desc|firstline}\n' + > [extensions] + > rebase = + > EOF + $ echo "evolve=$(echo $(dirname $TESTDIR))/hgext/evolve.py" >> $HGRCPATH + +example 3: safe amend with "hg commit --amend" (figure 2) + $ echo 'tweak feature Y' >> file1.c + $ hg commit --amend -u alice -d '2 0' -m 'implement feature Y' + $ hg shortlog -q -r fe0ecd3bd2a4 + abort: unknown revision 'fe0ecd3bd2a4'! + [255] + $ hg --hidden shortlog -G + @ 3:934359450037 draft implement feature Y + | + | x 2:6c5f78d5d467 draft temporary amend commit for fe0ecd3bd2a4 + | | + | x 1:fe0ecd3bd2a4 draft implement feature Y + |/ + o 0:08c4b6f4efc8 draft init + +example 3 redux: repeat safe amend, this time with "hg amend" + $ hg rollback -q + $ hg amend -u alice -d '2 0' -m 'implement feature Y' + $ hg --hidden shortlog -G + @ 3:934359450037 draft implement feature Y + | + | x 2:6c5f78d5d467 draft temporary amend commit for fe0ecd3bd2a4 + | | + | x 1:fe0ecd3bd2a4 draft implement feature Y + |/ + o 0:08c4b6f4efc8 draft init + +example 4: prune at head (figure 3) + $ echo 'debug hack' >> file1.c + $ hg commit -m 'debug hack' + $ hg prune . + 1 changesets pruned + 1 files updated, 0 files merged, 0 files removed, 0 files unresolved + working directory now at 934359450037 + $ hg parents --template '{rev}:{node|short} {desc|firstline}\n' + 3:934359450037 implement feature Y + $ hg --hidden shortlog -G -r 3: + x 4:a3e0ef24aaf0 draft debug hack + | + @ 3:934359450037 draft implement feature Y + | + +example 5: uncommit files at head (figure 4) + $ echo 'relevant' >> file1.c + $ echo 'irrelevant' >> file2.c + $ hg commit -u dan -d '10 0' -m 'fix bug 234' + $ hg uncommit file2.c + $ hg status + M file2.c + $ hg --hidden shortlog -G -r 'descendants(3) - 4' + @ 6:c8defeecf7a4 draft fix bug 234 + | + | x 5:da4331967f5f draft fix bug 234 + |/ + o 3:934359450037 draft implement feature Y + | + $ hg parents --template '{rev}:{node|short} {desc|firstline}\n{files}\n' + 6:c8defeecf7a4 fix bug 234 + file1.c + $ hg revert --no-backup file2.c + +example 6: fold multiple changesets together into one (figure 5) + $ echo step1 >> file1.c + $ hg commit -m 'step 1' + $ echo step2 >> file1.c + $ hg commit -m 'step 2' + $ echo step3 >> file2.c + $ hg commit -m 'step 3' + $ hg log --template '{rev}:{node|short} {desc|firstline}\n' -r 7:: + 7:05e61aab8294 step 1 + 8:be6d5bc8e4cc step 2 + 9:35f432d9f7c1 step 3 + $ hg fold -d '0 0' -m 'fix bug 64' -r 7:: + 3 changesets folded + 1 files updated, 0 files merged, 0 files removed, 0 files unresolved + $ hg --hidden shortlog -G -r 6:: + @ 10:171c6a79a27b draft fix bug 64 + | + | x 9:35f432d9f7c1 draft step 3 + | | + | x 8:be6d5bc8e4cc draft step 2 + | | + | x 7:05e61aab8294 draft step 1 + |/ + o 6:c8defeecf7a4 draft fix bug 234 + | + $ hg --hidden log -q -r 'successors(7) | successors(8) | successors(9)' + 10:171c6a79a27b + $ hg --hidden log -q -r 'precursors(10)' + 7:05e61aab8294 + 8:be6d5bc8e4cc + 9:35f432d9f7c1 + $ hg diff -c 10 -U 0 + diff -r c8defeecf7a4 -r 171c6a79a27b file1.c + --- a/file1.c Thu Jan 01 00:00:10 1970 +0000 + +++ b/file1.c Thu Jan 01 00:00:00 1970 +0000 + @@ -3,0 +4,2 @@ + +step1 + +step2 + diff -r c8defeecf7a4 -r 171c6a79a27b file2.c + --- a/file2.c Thu Jan 01 00:00:10 1970 +0000 + +++ b/file2.c Thu Jan 01 00:00:00 1970 +0000 + @@ -0,0 +1,1 @@ + +step3 + +setup for example 7: amend an older changeset + $ echo 'fix fix oops fix' > file2.c + $ hg commit -u bob -d '3 0' -m 'fix bug 17' + $ echo 'cleanup' >> file1.c + $ hg commit -u bob -d '4 0' -m 'cleanup' + $ echo 'new feature' >> file1.c + $ hg commit -u bob -d '5 0' -m 'feature 23' + $ hg --hidden shortlog -G -r 10:: + @ 13:dadcbba2d606 draft feature 23 + | + o 12:debd46bb29dc draft cleanup + | + o 11:3e1cb8f70c02 draft fix bug 17 + | + o 10:171c6a79a27b draft fix bug 64 + | + +example 7: amend an older changeset (figures 6, 7) + $ hg update -q 11 + $ echo 'fix fix fix fix' > file2.c + $ hg amend -u bob -d '6 0' + 2 new unstable changesets + $ hg shortlog -r 'obsolete()' + 11:3e1cb8f70c02 draft fix bug 17 + $ hg shortlog -r 'unstable()' + 12:debd46bb29dc draft cleanup + 13:dadcbba2d606 draft feature 23 + $ hg --hidden shortlog -G -r 10:: + @ 15:395cbeda3a06 draft fix bug 17 + | + | x 14:f7fab707e247 draft temporary amend commit for 3e1cb8f70c02 + | | + | | o 13:dadcbba2d606 draft feature 23 + | | | + | | o 12:debd46bb29dc draft cleanup + | |/ + | x 11:3e1cb8f70c02 draft fix bug 17 + |/ + o 10:171c6a79a27b draft fix bug 64 + | + $ hg evolve -q --all + $ hg shortlog -G -r 10:: + @ 17:91b4b0f8b5c5 draft feature 23 + | + o 16:fe8858bd9bc2 draft cleanup + | + o 15:395cbeda3a06 draft fix bug 17 + | + o 10:171c6a79a27b draft fix bug 64 + | + +setup for example 8: prune an older changeset (figure 8) + $ echo 'useful' >> file1.c + $ hg commit -u carl -d '7 0' -m 'useful work' + $ echo 'debug' >> file2.c + $ hg commit -u carl -d '8 0' -m 'debug hack' + $ echo 'more useful' >> file1.c + $ hg commit -u carl -d '9 0' -m 'more work' + $ hg shortlog -G -r 17:: + @ 20:ea8fafca914b draft more work + | + o 19:b23d06b457a8 draft debug hack + | + o 18:1f33e68b18b9 draft useful work + | + o 17:91b4b0f8b5c5 draft feature 23 + | + +example 8: prune an older changeset (figures 8, 9) + $ hg prune 19 + 1 changesets pruned + 1 new unstable changesets + $ hg --hidden shortlog -G -r 18:: + @ 20:ea8fafca914b draft more work + | + x 19:b23d06b457a8 draft debug hack + | + o 18:1f33e68b18b9 draft useful work + | + $ hg evolve -q --all + $ hg --hidden shortlog -G -r 18:: + @ 21:4393e5877437 draft more work + | + | x 20:ea8fafca914b draft more work + | | + | x 19:b23d06b457a8 draft debug hack + |/ + o 18:1f33e68b18b9 draft useful work + | + +example 9: uncommit files from an older changeset (discard changes) +(figure 10) + $ echo 'this fixes bug 53' >> file1.c + $ echo 'debug hack' >> file2.c + $ hg commit -u dan -d '11 0' -m 'fix bug 53' + $ echo 'and this handles bug 67' >> file1.c + $ hg commit -u dan -d '12 0' -m 'fix bug 67' + $ hg update 22 + 1 files updated, 0 files merged, 0 files removed, 0 files unresolved + $ hg shortlog -G -r 21:: + o 23:4db2428c8ae3 draft fix bug 67 + | + @ 22:f84357446753 draft fix bug 53 + | + o 21:4393e5877437 draft more work + | + $ hg uncommit file2.c + 1 new unstable changesets + $ hg status + M file2.c + $ hg revert file2.c + $ hg evolve --all + move:[23] fix bug 67 + atop:[24] fix bug 53 + $ hg --hidden shortlog -G -r 21:: + @ 25:0d972d6888e6 draft fix bug 67 + | + o 24:71bb83d674c5 draft fix bug 53 + | + | x 23:4db2428c8ae3 draft fix bug 67 + | | + | x 22:f84357446753 draft fix bug 53 + |/ + o 21:4393e5877437 draft more work + | + $ rm file2.c.orig + +example 10: uncommit files from an older changeset (keep changes) +(figures 11, 12) + $ echo 'fix a bug' >> file1.c + $ echo 'useful but unrelated' >> file2.c + $ hg commit -u dan -d '11 0' -m 'fix a bug' + $ echo 'new feature' >> file1.c + $ hg commit -u dan -d '12 0' -m 'new feature' + $ hg update 26 + 1 files updated, 0 files merged, 0 files removed, 0 files unresolved + $ hg --hidden shortlog -G -r 25:: + o 27:fbb3c6d50427 draft new feature + | + @ 26:5b31a1239ab9 draft fix a bug + | + o 25:0d972d6888e6 draft fix bug 67 + | + $ hg uncommit file2.c + 1 new unstable changesets + $ hg status + M file2.c + $ hg commit -m 'useful tweak' + $ hg --hidden shortlog -G -r 25:: + @ 29:51e0d8c0a922 draft useful tweak + | + o 28:2594e98553a9 draft fix a bug + | + | o 27:fbb3c6d50427 draft new feature + | | + | x 26:5b31a1239ab9 draft fix a bug + |/ + o 25:0d972d6888e6 draft fix bug 67 + | + $ hg evolve --all + move:[27] new feature + atop:[28] fix a bug + $ hg --hidden shortlog -G -r 25:: + @ 30:166c1c368ab6 draft new feature + | + | o 29:51e0d8c0a922 draft useful tweak + |/ + o 28:2594e98553a9 draft fix a bug + | + | x 27:fbb3c6d50427 draft new feature + | | + | x 26:5b31a1239ab9 draft fix a bug + |/ + o 25:0d972d6888e6 draft fix bug 67 + |