pick: remove transaction on the whole command (issue6037)
At its core, pick is a pretty straightforward and well-behaving command, it
uses functions already in core hg, it checks that wdir is clean and that
changeset to pick is not public, it checks if there happen to be merge
conflicts and can be --continue'd later, etc.
It is very similar to graft in core (it also uses mergemod.graft function), but
it obsoletes the original changeset. However, graft does not experience this
incorrect behavior from issue 6037.
What happens in the test case for this issue when we pick a revision that
touches both "a" and "b": mergemod.graft() takes the original changeset and
tries to apply it to the wdir, which results in "b" being marked as newly added
and ready to be committed, "a" updated with the new content and being marked as
modified, but "a" also has conflicts. Pick correctly notices this and saves its
state before asking for user intervention. So far so good. However, when the
command raises InterventionRequired to print a user-facing message and exit
while being wrapped in repo.transaction() context manager, the latter partially
undoes what mergemod.graft() did: it unmarks "b" as added. And when user
continues pick, "b" is therefore not tracked and is not included in the
resulting commit.
The transaction is not useful here, because it doesn't touch wdir (it's still
dirty), it doesn't remove pickstate (and other commands will refuse to work
until pick --abort or --continue), it just makes "b" untracked.
The solution is to use repo.transaction() only to wrap code that writes data to
hg store in the final stages of the command after all checks have passed and is
not expected to fail on trivial cases like merge conflicts. For example,
committing the picked changeset. But since pick uses repo.commit() for that,
and because that function already uses a transaction, wrapping it in another
transaction doesn't make sense.
=============================
Mutable History For Mercurial
=============================
Evolve Extension
=================
This package supplies the ``evolve`` extension for Mercurial,
**The full implementation of the changeset evolution concept is still in
progress.** Please subscribe to the `evolve-testers mailing list
<https://www.mercurial-scm.org/mailman/listinfo/evolve-testers>`_ to stay up to
date with changes.
This extension:
* enables the “changeset evolution” feature of Mercurial core,
* provides a set of commands to mutate your history,
* issues several warning messages when troubles from some mutable appears in
your repository,
* provides an ``hg evolve`` command to deal with such "troubles",
* improves performance of obsolescence marker exchanges and discovery during
push and pull.
Documentation
-------------
We recommend reading the documentation first. An online version is
available here:
https://www.mercurial-scm.org/doc/evolution/
How to Install
==============
Using Pip
---------
You can install the latest evolution version usin pip::
$ pip install --user hg-evolve
Then just enable it in you hgrc::
$ hg config --edit # adds the two line below:
[extensions]
evolve =
From Source
-----------
To install a local version from source::
$ hg clone https://www.mercurial-scm.org/repo/evolve/
$ cd evolve
$ pip install --user .
Then just enable it in you hgrc::
$ hg config --edit # adds the two line below:
[extensions]
evolve =
Documentation lives in ``doc/``.
Server Only Setup
=================
It is possible to enable a smaller subset of the extensions aimed at server
serving repository. It skips the additions of the new commands and local UI
messages that might add performance overheads. To use the server only
extension, install the package and use::
$ hg config --edit # adds the two line below:
[extensions]
evolve.serveronly =
Extension Purpose
=================
The goal of this extension is to provide an appropriate place for code and
concept related to changeset evolution to mature. In this extension we allow
for hackier code, unlocking quick experimentation and faster iterations.
In addition, the evolve extensions support a wider set of Mercurial version,
allowing us to reach a larger user base for feedback. The Evolve extension is
not tight to the Mercurial release cycle and can release new feature and bug
fix at a higher rate if necessary.
Once a concept is ready enough, its implementation is moved into Mercurial
core. The maturation period helped us to get a clearer picture of what was
needed. During the upstreaming process, we can use this clearer picture to
clean up the code and upgrade it to an appropriate quality for Mercurial core.
How to Contribute
=================
Discussion happens on the #hg-evolve IRC on freenode_.
.. _freenode: https://freenode.net/
Bugs are to be reported on the mercurial's bug tracker (component: `evolution`_):
.. _evolution: https://bz.mercurial-scm.org/buglist.cgi?component=evolution&query_format=advanced&resolution=---
You can use the patchbomb extension to send email to `mercurial devel
<https://www.mercurial-scm.org/mailman/listinfo/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@mercurial-scm.org --flag evolve-ext --rev '<your patches>'
Some of development happens on a public bitbucket repository (`evolve-devel`_) using the topic extension.
.. _`evolve-devel`: https://bitbucket.org/octobus/evolve-devel
For guidelines on the patch description, see the `official Mercurial guideline`_.
.. _`official Mercurial guideline`: https://mercurial-scm.org/wiki/ContributingChanges#Patch_descriptions
Please don't forget to update and run the tests when you fix a bug or
add a feature. To run the tests, you need a working copy of Mercurial,
say in $HGSRC::
$ cd tests
$ python $HGSRC/tests/run-tests.py
Branch policy
-------------
The evolve test are highly impacted by changes in core. To deal with this, we use named branches.
There are two main branches: "stable" and "default". Tests on these branch are
supposed to pass with the corresponding "default" and "stable" branch from core
Mercurial. The documentation is built from the tip of stable.
In addition, we have compatibility branches to check tests on older version of
Mercurial. They are the "mercurial-x.y" branches. They are used to apply
expected test change only, no code change should happen there.
test output change from a changeset in core should adds the following line to their description:
CORE-TEST-OUTPUT-UPDATE: <CORE-NODE-ID>