Mercurial

Short version (rename from $OLD to $NEW):

ROOT="$(hg id -qr 'first(roots(branch('$OLD')))')"
MSG="$(hg log -r $ROOT -T '{desc}')"  

hg update $ROOT
hg branch $NEW
hg commit --amend -m "$MSG"
hg evolve --all

Mercurial records in which named branch a commit was created. This can be inconvenient when you choose temporary branch names like "foo" or "justworkdamnit".

The evolve extension enables safe, collaborative history editing which removes this inconvenience while preserving the reliability guarantees of Mercurial.

Here I show in a quick example how to rename a branch in Mercurial using the evolve extension.

You can use this method for all changes which you did not transfer elsewhere yet (they must be in draft or secret phase).

Note (2016): The evolve extension is still in testing. Do not use it for production yet. If you want to help stabilizing it, please join evolve-testers. I’ve been using it for more than a year, but I know how to fix things when I hit a bug in the evolve extension.

A comment on largefile support missing in BitBucket, despite being a much-requested feature since 2012.

Note that it’s not Atlassian which got big with Mercurial. It’s Bitbucket which got big with Mercurial, and it was later bought by Atlassian.

# freenet -> local
hg clone freenet://ArneBab/life-repo
# local -> freenet
hg clone life-repo real-life
hg clone real-life freenet://ArneBab/real-life
# send pull request
cd real-life
hg fn-pull-request --wot ArneBab/life-repo
(enter message)
# check for pull-requests
cd ../life-repo
sleep 1800 # (wait for confidential delivery)
hg fn-check-notifications --wot ArneBab

If you like this, please don’t only click like or +1, but share it with everyone who could be interested. The one who knows best how to reach your friends is you — and that’s how it should be.

In many discussions on DVCS over the years I have been fair, friendly and technical while receiving vitriol and misinformation and FUD. This strip visualizes the impression which stuck to my mind when speaking with casual git-users.

Update: I found a very calm discussion at a place where I did not expect it: reddit. I’m sorry to you, guys. Thank you for proving that a constructive discussion is possible from both sides! I hope that you are not among the ones offended by this strip.

To Hg-users: There are git users who really understand what they are doing and who stick to arguments and friendly competition. This comic arose from the many frustrating experiences with the many other git users. Please don’t let this strip trick you into going down to non-constructive arguments. Let’s stay friendly. I already feel slightly bad about this short move into competition-like visualization for a topic where I much prefer friendly, constructive discussions. But it sucks to see contributors stumble over git, so I think it was time for this.

»I also think that git isn’t the most beginner-friendly program. That’s why I’m using only its elementary features«

To put the strip in words, let’s complete the quote:

»I also think that git isn’t the most beginner-friendly program.
That’s why I’m using only its elementary features«
<ArneBab> I hear that from many git-users…
»oh, maybe I should have another look at hg after all«

Why this?

Because there are far too many Git-Users who only dare using the most basic commands which makes git at best useless and at worst harmful.

This is not the fault of the users. It is the fault of the tool.

This strip is horrible!

If you are offended by this strip: You knew the title when you came here, right?

And if you are offended enough, that you want to make your own strip and set things right, go grab the source-file, fire up krita and go for it! This strip is free.¹

Commentary

If you feel that this strip fits Mercurial and Git perfectly, keep in mind, that this is only one aspect of the situation, and that using Git is still much better than being forced to use centralized or proprietary version tracking (and people who survive the initial phase mostly unscarred can actually do the same with Git as they could with Mercurial).

Update 2016: Instead of fixing the article, the Atlassian web workers removed the comments which point out the misinformation in the article. *sigh*

2 years ago, Atlassian developer Charles O’Farrell published the article Git vs. Mercurial: Why Git? in which he claimed to show "the winning side of Git”. This article was part of the Dev Tools series at Atlassian and written as a reply to the article Why Mercurial?. It was spiced with so much misinformation about Mercurial (statements which were factually wrong) that the comments exploded right away. But the article was never corrected. Just now I was referred to the text again, and I decided to do what I should have done 2 years ago: Write an answer which debunks the myths.

“I also think that git isn’t the most beginner-friendly program. That’s why I’m only using its elementary features” — “I hear that from many git-users …” — part of the discussion which got me to write this article

If you came here searching for a way to set the username in Mercurial: just run hg config --edit and add
    [ui]
    username = YOURNAME <EMAIL>
to the file which gets opened. If you have a very old version of Mercurial (<3.0), open $HOME/.hgrc manually.

Update (2015-02-05): For the Git breakage there is now a partial solution in Git v2.3.0: You can push into a checked out branch when you prepare the target repo via git config receive.denyCurrentBranch updateInstead, but only if nothing was changed there. This does not fully address the workflow breakage (the success of the operation is still state-dependent), but at least it makes it work. With Git providing a partial solution for the breakage I reported and Mercurial providing a full solution since 2014-05-01, I call this blog post a success. Thank you Git and Mercurial devs!

Update (2014-05-01): The Mercurial breakage is fixed in Mercurial 3.0: When you commit without username it now says “Abort: no username supplied (use "hg config --edit" to set your username)”. The editor shows a template with a commented-out field for the username. Just put your name and email after the pre-filled username = and save the file. The Git breakage still exists.

Update (2013-04-18): In #mercurial @ irc.freenode.net there were discussions yesterday for improving the help output if you do not have your username setup, yet.

New version: draketo.de/software/mercurial-branching-strategy

This is a complete collaboration model for Mercurial. It shows you all the actions you may need to take, except for the basics already found in other tutorials like

• Mercurial in workflows (official guide, 15 minutes)
• hg init (more graphics and for Windows)
• hg init science (slides 12 to 23)

Adaptions optimize the model for special needs like maintaining multiple releases¹, grafting micro-releases and an explicit code review stage.

Summary: 3 simple rules

Any model to be used by people should consist of simple, consistent rules. Programming is complex enough without having to worry about elaborate branching directives. Therefore this model boils down to 3 simple rules:

3 simple rules:

(1) you do all the work on default² - except for hotfixes.

(2) on stable you only do hotfixes, merges for release³ and tagging for release. Only maintainers⁴ touch stable.

(3) you can use arbitrary feature-branches⁵, as long as you don’t call them default or stable. They always start at default (since you do all the work on default).

Diagram

To visualize the structure, here’s a 3-tiered diagram. To the left are the actions of programmers (commits and feature branches) and in the center the tasks for maintainers (release and hotfix). The users to the right just use the stable branch.⁶

An overview of the branching strategy. Click the image to get the emacs org-mode ditaa-source.

Table of Contents

• Summary
  • Diagram
• Practical Actions
  • Regular development
  • Feature branches
  • Tasks for maintainers
• Example
  • Initialize
  • Stable branch and first release
  • Further development
  • Hotfix
  • Regular release
  • Feature branches
• Adaptions
  • multiple maintained releases
  • Graft changes into micro releases
  • Explicit review branch
• Frequently Asked Questions (FAQ)
  • Where does QA (Quality Assurance) come in?
• Summary

Practial Actions

Now we can look at all the actions you will ever need to do in this model:⁷

• Regular development

  • commit changes: (edit); hg ci -m "message"

  • continue development after a release: hg update; (edit); hg ci -m "message"

• Feature Branches

  • start a larger feature: hg branch feature-x; (edit); hg ci -m "message"

  • continue with the feature: hg update feature-x; (edit); hg ci -m "message"

  • merge the feature: hg update default; hg merge feature-x; hg ci -m "merged feature x into default"

  • close and merge the feature when you are done: hg update feature-x; hg ci --close-branch -m "finished feature x"; hg update default; hg merge feature-x; hg ci -m "merged finished feature x into default"

• Tasks for Maintainers

  • Initialize (only needed once)

    • create the repo: hg init reponame; cd reponame

    • first commit: (edit); hg ci -m "message"

    • create the stable branch and do the first release: hg branch stable; hg tag tagname; hg up default; hg merge stable; hg ci -m "merge stable into default: ready for more development"

  • apply a hotfix⁸: hg up stable; (edit); hg ci -m "message"; hg up default; hg merge stable; hg ci -m "merge stable into default: ready for more development"

  • do a release⁹: hg up stable; hg merge default; hg ci -m "(description of the main changes since the last release)" ; hg tag tagname; hg up default ; hg merge stable ; hg ci -m "merged stable into default: ready for more development"

That’s it. All that follows are a detailed example which goes through all actions one-by-one, adaptions to this workflow and the final summary.

In the mercurial list Stanimir Stamenkov asked how to get rid of intermediate merges in the log to simplify reading the history (and to not care about missing some of the details).

Update: Since Mercurial 2.4 you can simply use
hg log -Gr "branchpoint()"

I did some tests for that and I think the nicest representation I found is this:

hg log -Gr "(all() - merge()) or head()"

This article shows examples for this.

Also published on Mercurials Workflows wikipage. Originally written for PyHurd: Python bindings for the GNU Hurd.

For Whom?

If you

1. want to develop features collaboratively and you want to be able to see later for which feature a given change was added or
2. want to do changes concurrently which would likely affect each other negatively while they are not finished, but which need to be developed in a group with minimal overhead,

then this workflow might be right for you.

Note: If you have a huge number of small features (2000 and upwards), the number of persistent named branches can create some performance problems for listing the branches (only for the listing!) (as different example, pushing is unaffected: Linear history is just as fast as 2000 branches). For features which need no collaboration or need only a few commits, this workflow also has much unnecessary overhead. It is best used for features which will be developed side by side with default for some time (and many commits), so tracking the default branch against the feature is relevant. To mark single-commit features as belonging to a feature, just use the commit message.

Note: The difference between Mercurial named branches and git branches is that git branches don’t stay in history. They don’t allow you to find out later in which branch a certain commit was added. If you want git-style branching, just use bookmarks.

Note: If you avoid using stable as branch name, you can always upgrade this workflow to the complete branching model later on.

The official workflow guide for Mercurial, mirrored from mercurial-scm.org/guide. License: GPLv2 or later.

It delves into nonlinear history and merging right from the beginning and uses only features you get without activating extensions. Due to this it offers efficient and safe workflows without danger of losing already committed work.

• Basic workflows
• Log keeping
• Lone developer with nonlinear history
• Separate features
• Sharing changes
• Summary
• Advanced workflows
• Backing out bad revisions
• Collaborative feature development
• Tagging revisions
• Removing history
• Summary
• More complex workflows
• License

Anonymous DVCS in the Darknet.

This is a mirror of the documentation of the infocalypse extension for Mercurial written by djk - published here with his permission. It is licensed solely under the GPLv2 or later. The text is long. For concise information, use the second Link above (Freenet Development over Freenet).

Introduction

The Infocalypse 2.0 hg extension is an extension for Mercurial that allows you to create, publish and maintain incrementally updateable repositories in Freenet.

Your code is then hosted decentrally and anonymously, making it just as censorship-resistant as all other content in Freenet.

It works better than the other DVCS currently available for Freenet.

Most of the information you will find in this document can also be found in the extension's online help. i.e.:

hg help infocalypse

If you want to publish your scientific scripts, as Nick Barnes advises in Nature, you can very easily do so with Mercurial.

All my stuff (not just code), excempting only huge datasets, is in a Mercurial source repository.¹

Whenever I change something and it does anything new, I commit the files with a simple commit (even if it’s only “it compiles!”).

→ comment to The next wave in scholarly word processors?

What I’d like to see is more people using version tracking systems.

With these you have a discussion which can be merged easily when it gets branched. I use it for anything I do, and I could use it together with an only-windows-and-GUI user with ease, installing TortoiseHG for both and Lyx for him (LaTeX made easy – you don’t have to see the sources).

Why?

What I miss in the internet is the notion of being able to control what my apps access for data.

Why can’t a chat application just connect to a neighborhood- or community-server, and why can’t the activity-stream come from the people I know — and query only their systems, like jabber does?

Almost all geolocation services should be implementable over direct friend-to-friend connections like jabber, and I don’t really see why my local identi.ca program can’t also get the news from my local jabber contacts.

Note: This tutorial is for the old TortoiseHG (with gtk interface). The new one works a bit differently (and uses Qt). See the official quick start guide. The right-click menus should still work similar to the ones described here, though.

Downloading the Repository

After installing TortoiseHG, you can download a repository to your computer by right-clicking in a folder and selecting the menu "TortoiseHG" and then "Clone" in there (currently you still need Windows for that - all other dialogs can be evoked in GNU/Linux on the commandline via "hgtk").

Right-Click menu, Windows:

Goal

A workflow where the repository gets updated only from repositories whose heads got signed by at least a certain percentage or a certain number of trusted committers.

Requirements

Mercurial, two hooks for checking and three special files in the repo.

The hooks do all the work - apart from them, the repo is just a normal Mercurial repository. After cloning it, you only need to setup the hooks to activate the workflow.

Extensions: gpg

Hooks: prechangegroup and pretxnchangegroup

Note: This tutorial is for the old TortoiseHG (with gtk interface). The new one works a bit differently (and uses Qt). See the official quick start guide. The right-click menus should still work similar to the ones described here, though.

Das Repository herunterladen

Wenn du TortoiseHG installiert hast, kannst du dir das Repository auf den Rechner laden, indem du in einem Ordner rechtsklickst und im Menü "TortoiseHG" die Option "Clone" wählst (Aktuell brauchst du für den Dialog noch Windows, die anderen gibt es auch in GNU/Linux).

Rechtsklick-Menü, Windows:

Clone, GNU/Linux:

We (nelchael and me) just finished a live ebuild for Mercurial which allows to conveniently track the main (mpm) repo of Mercurial in Gentoo.

To use the ebuild, just add

=dev-util/mercurial-9999 **  

to your package.keywords and emerge mercurial (again).

Anonymous DVCS in the Darknet.

There is a new Mercurial extension for interaction with Freenet called "infocalypse" (which should keep working after the information apocalypse).

It offers "fn-push" and "fn-pull" as an optimized way to store code in freenet: bundles are inserted and pulled one after the other. An index tells infocalypse in which order to pull the bundles. It makes using Mercurial in freenet far more efficient and convenient.

Also you can use it to publish collaborative anonymous websites like the freefaq and Technophob.

And it is a perfect fit for the workflow automatic trusted group of committers.

Otherwise it offers the same features as FreenetHG.

Mercurial is a distributed source control management tool.

With it you can save snapshots of your work on documents and go back to these at all times.

Also you can easily collaborate with other people and use Mercurial to merge your work.

Written in the Mercurial mailing list

Hi Bernard,

Am Dienstag 03 Februar 2009 20:19:14 schrieb ... ...:
> Most of the docs I can find seem to assume the reader is familiar with
> existing software developemnt tools and methodologies.
>
> This is not the case for me.

It wasn't for me either, and I can assure you that using Mercurial becomes
natural quite quickly.

Some folks in #mercurial @ freenode.net just repeated the tests, so we have now a bit more stable data.

The evaluation shows the following:

1. Initial clone: hg is about 4.4 times faster (about 2 min vs. 6 to 15 min)
2. Repository sizes: the hg repo is about 1.92 smaller (~113M vs. 215M)
3. Time for a full log: hg is about 2.36 times faster (~21s vs. ~50s)
4. Time for annotating Misc/NEWS: hg is 1.5 times slower than bzr.
   Without the result from bzr-1.6.1 it is 2.6 times slower (~43s vs 17s).
5. Integrity checking: hg is by several orders of magnitude faster than bzr which just took too long - everyone stopped it after varying time (30s to 17 min), because the output spoke of hours remaining, one had an integrity error. hg needed about 1 min.
6. Local clone: hg is 11 times faster (39s vs. 7.14 min).
   Without the 1m15 result from the high disk load host it is 16 times faster (26s).
7. Local clone with hot filesystem: hg is 14.9 times faster (26s vs. 6.5 min).
8. Hot copy of just .bzr / .hg: The speeds are about equal, so the difference doesn't come from raw filesystem speed (2s).
9. Additional Bazaar tests to check shared repository cloning performance (you only get this when you use a shared repository and only clone that shared repository): With shared repository and hardlinks bzr only needs about 5 seconds for cloning.

I repeatet my test with the provided Python 2.x repos from the DVCS PEP for Python to check the performance of Bazaar and Mercurial.

All these tests are done only once with some mostly constant load, so they don't qualify as scientific tests, but they give a good impression of the differences between Bazaar (bzr) and Mercurial (hg).

Versions:
- Bazaar 1.10
- Mercurial 1.1

This comparision should be fair since Bazaar 1.10 is more recent, but Mercurial 1.1 is a major release.

I just did a test with the provided Python 2.x repos from the DVCS PEP for Python to check the performance of Bazaar and Mercurial.

(this is a slightly changed version of a mail posted to the mercurial list: http://selenic.com/pipermail/mercurial/2008-November/022199.html )

All these tests are done only once with some mostly constant load, so they don't qualitfy as scientific tests, but they give a good impressing of the differences between Bazaar (bzr) and Mercurial (hg).

Versions:
- Bazaar 1.5
- Mercurial 1.0.2

These are the ones which are marked as stable in my Gentoo tree (amd64).

Vergleiche | Comparisions

Englisch

English: A speed test for Mercurial and git (in german). -> Links to other tests. Update: I wrote a new test for use in server applications, since they are the only place where a difference of 30-60ms really matters: hg vs. git for server applications.

Ich habe ein paar Testsskripte geschrieben, um die lokale Leistung von Mercurial und GIT vergleichen zu können.

Mercurial ist ein verteiltes Versionsverwaltungssystem.

-> Webseiten auf den FTP-Server laden wird einfach "hg push".

Ich schreibe seit langem eigene Webseiten, und die Notwendigkeit, sie jedesmal von Hand auf den Server hochzuladen, wenn ich etwas geändert hatte, war mir seit Jahren ein Dorn im Auge.

Vor kurzem habe ich nun angefangen, die Webseiten mit Mercurial als Versionsverwaltung zu bearbeiten, und Mercurial hat eine sehr praktische Funktion: Hooks (also Anker).

Damit kann ich einen Befehl ausführen, wenn ich in meiner Versionsverwaltung eine bestimmte Handlung ausführe.