1. 8

This is a little old, and sadly, Evolve has stayed in perpetual beta since this came out. It’s been under development for a long time.

However, the core ideas have not changed, and as I was looking this over, I was still happy with how I explained ideas in here. I think Evolve is a really good idea worth spreading, hopefully something that another VCS like git will some day adopt if using Mercurial itself is impossible.

  1.  

  2. 5

    We have been using mercurial evolution here for a couple of years.

    It’s superb.

    Some of the Big Advantages are…

    • Your feature branches never grow stale and suffer from the 20 man days a day problem. (ie. when your 20 coworkers dump 20 man days of churn into the mainline for every day you are out on a branch. You can rebase your branch ontop of the latest (successful) mainline build as often as you want.)
    • You can create topical commits. ie. you can amend, split, rebase and fold your commits until…
    1. Each one compiles, links and runs all tests.
    2. Is a single, complete standalone change. eg. If you wish to rename a function, you can have a commit that is just that change in the .h, the implementation and all references in all files and a commit log that explains why.
    3. You can collaborate with a coworker on a something that is really “not fit for public consumption” and evolve it together into something that is. (NB: This requires close cooperation and keeping your head screwed on. Concurrently mutating shared state should scare you.)
    1. 1

      Have you tried doing the above things in git? Interested to know if you found things different.

      1. 2

        Yes, in principle you can do all these things in git. (Especially if you’re an emacs user using Magit)

        In practice it’s just so much easier in mercurial.

        I’m not quite sure why, but git really does leak it’s fundamental internal design into your actions. ie. You can’t just think what you want to do in git, you have to expend many brain cycles on what git is doing (and how).

        Branches in git and mercurial are quite different in that an hg commit records which branch it was made on. And if life really turns shitty, you can look at the hidden obsolete commits.

        This core difference is exemplified by this koan… http://stevelosh.com/blog/2013/04/git-koans/#only-the-gods

        Only the Gods

        The great historian was trying to unravel the intricacies of an incorrect merge that had happened many months ago. He made a pilgrimage to Master Git to ask for his help.

        “Master Git,” said the historian, “what is the nature of history?”

        “History is immutable. To rewrite it later is to tamper with the very fabric of existence.”

        The historian nodded, then asked: “Is that why rebasing commits that have been pushed is discouraged?”

        “Indeed,” said Master Git.

        “Splendid!” exclaimed the historian. “I have a historical record of a merge commit with two parents. How can I find out which branch each parent was originally made on?”

        “History is ephemeral,” replied Master Git, “the knowledge you seek can be answered only by the gods.”

        The historian hung his head as enlightenment crushed down upon him.

        1. 3

          Hmm, it’s true to an extent that you need to somewhat plan out your steps when doing things in git. It’s like a state machine where you need to be aware of the current state before doing something to change it. A lot of it is probably because of the index. That Mercurial doesn’t have that probably simplifies some usages.

          Regarding branches, I thought nowadays the best practice in Mercurial was to use bookmarks anyway. And, nothing is stopping you from keeping old branches around in a git repo. Sure, you’re doing it ‘by hand’ instead of Mercurial doing changeset evolution for you, but honestly this seems like a bit of an edge case :-)

          Regarding the great historial and the incorrect merge, I see what the problem was. They should have rebased in the first place instead of merging ;-)

          P.S. nowadays I advocate for GitHub’s ‘Squash & Merge’–it’s really nice, it keeps the old branch around while merging just a single squashed commit into the integration branch. Best of both worlds!

          1. 1

            Bookmarks are a helpful complementary tool… although I find them a little irritating in that unless you’re paying attention they can be bumped and or pushed when you you weren’t expecting it (because you had forgotten about them).

            1. 1

              Isn’t there a setting to turn off bumping and pushing bookmarks by default unless explicitly specified?

              1. 1

                Creating or updating to a bookmark causes it to be marked as ‘active’. The active bookmark is indicated with a ‘*’. When a commit is made, the active bookmark will advance to the new commit. A plain ‘hg update’ will also advance an active bookmark, if possible. Updating away from a bookmark will cause it to be deactivated.

                To mark one as inactive..

                hg bookmark -i NAME

                From hg push –help

                If -B/–bookmark is used, the specified bookmarked revision, its ancestors, and the bookmark will be pushed to the remote repository. Specifying “.” is equivalent to specifying the active bookmark’s name

                By default all bookmarks on the server are updated on the client on pull, and all bookmarks that are already present on both the client and server are updated on the server on push.

                To start sharing a bookmark present on a server, use hg pull -B bookmark and the bookmark along with the relevant changesets will be pulled to the client.

                To publish a local bookmark to a server, use hg push -B bookmark and the bookmark along with the relevant changesets will be pushed to the server. To delete a bookmark from a server, delete it locally first, then use push -B on the deleted name.

                To check which bookmarks exist on the remote repository but not locally use hg incoming -B. Use hg outgoing -B to check which bookmarks exists locally but not yet on the remote repository.

                Be aware that there is only one namespace for bookmarks - it is advised to prefix your local-only bookmarks to avoid

                Yup, so they are easy to use…. except when you forget about them and you and your coworker are evolving things and forget about them.

                1. 1

                  Sounds like the UI around bookmarks could be improved.

                  1. 1

                    Either that or the use case that the author had for them is not the use case I’m using them for.

                    I don’t think they were developed with heavy use of evolution in mind, but that’s OK.