Mercurial

Renaming a Mercurial branch with the evolve extension

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.

Conveniently merge a NEWS file without conflicts

Writing a NEWS file (a list of changes per version, targeted at end-users) significantly reduces the effort for doing a release: To write your release notes, just copy the latest entries from the NEWS file into a message. It is one of the gems in the GNU coding standards: Simple yet extremely useful. (For a detailed realization, refer to the Perl Specification for CPAN Changes files.)

However when you’re developing features in parallel, for example by using a pull-request workflow and requiring contributors to update the NEWS file, you will often run into merge conflicts. Resolving these takes time, though the resolution is trivial: Just use the lines from both heads.

To resolve the problem, you can set your version tracking system to use union-merge for NEWS files.

BitBucket got big on Mercurial — until they got bought by Atlassian

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.

Real Life Infocalypse

Freenet Logo: Follow the Rabbit DVCS in the Darknet. The decentralized p2p code repository.

In this guide I show by example how you can use the Infocalypse plugin for distributed development without central point of failure or reliance on unfree tools.12

If you think “I have no idea what this tool is for”: Infocalypse gives you fully decentralized Github with real anonymity, using only free software.

# 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.


  1. This guide shows the convenient way of working which has a higher barrier of entry. It uses WoT Pseudonyms to allow you to insert repositories by Pseudonym and repository name. If you can cope with inserting by private key and sending pull-requests manually, you can use it without the WoT, too, which reduces the setup effort quite a bit. Just skip the setup of the Web of Trust and Freemail and plugins. You can then clone the life repo via hg clone freenet://USK@6~ZDYdvAgMoUfG6M5Kwi7SQqyS-gTcyFeaNN1Pf3FvY,OSOT4OEeg4xyYnwcGECZUX6~lnmYrZsz05Km7G7bvOQ,AQACAAE/life-repo.R1/4 life-repo. See hg fn-genkey and hg help infocalypse for details. 

  2. Infocalypse shows one of many really interesting possibilities offered by Freenet. To get a feeling of how much more is possible, have a look at The Forgotten Cryptopunk Paradise

git vs. hg - offensive

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«

git vs. hg - offensive

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.1

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).


  1. All the graphics in this strip are available under free licenses: creative-commons attribution or GPLv3 or later — you decide which of those you use. If it is cc attribution, call me Arne Babenhauserheide and link to this article. You’ll find all the sources as well as some preliminary works and SVGs in git-vs-hg-offensive.tar_.gz or git-vs-hg-offensive.zip (whichever you prefer)

    cc by GPLv3

Factual Errors in “Git vs Mercurial: Why Git?” from Atlassian

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

Summary:

  • Due to automatic garbage collection, history editing in git unpredictably loses unreferenced history while Mercurial stores permanent backups which can be retrieved with core commands.
  • Mercurial bookmarks are namespaced with bookmark@path when there could be confusion. This is equivalent to git’s use of path/branch, but only used where it is needed while git forces the user to always make that distinction.
  • Activating mercurial queues (mq) and the record extension provides a staging area like the git index — for those who want it.
  • Git and Mercurial provide the same raw power (as proved by transparent access with Mercurial to Git repos via hg-git), but
  • its “cuddly command line” gives Mercurial an efficiency during actual usage which most people do not find in Git.

2 years ago, Atlassian developer Charles O’Farrell published the article Git vs. Mercurial: Why Git? in which he claimed he “showed 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

Basic usecases for DVCS: Workflow Failures

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 (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.

1 Intro

I recently tried contributing to a new project again, and I was quite surprised which hurdles can be in your way, when you did not setup your environment, yet.

So I decided to put together a small test for the basic workflow: Cloning a project, doing and testing a change and pushing it back.

I did that for Git and Mercurial, because both break at different points.

I’ll express the basic usecase in Subversion:

  • svn checkout [project]
  • (hack, test, repeat)
  • (request commit rights)
  • svn commit -m "added X"

You can also replace the request for commit rights with creating a patch and sending it to a mailing list. But let’s take the easiest case of a new contributor who is directly welcomed into the project as trusted committer.

dvcs-basic-svn.png

A slightly more advanced workflow adds testing in a clean tree. In Subversion it looks almost like the simple commit:

dvcs-basic-svn-testing.png

Test of the hg evolve extension for easier upstreaming

1 Rationale

PDF-version (for printing)

orgmode-version (for editing)

repository (for forking)

Currently I rework my code extensively before I push it into upstream SVN. Some of that is inconvenient and it would be nicer to have easy to use refactoring tools.

hg evolve might offer that.

This test uses the mutable-hg extension in revision c70a1091e0d8 (24 changesets after 2.1.0). It will likely be obsolete, soon, since mutable-hg is currently moved into Mercurial core by Pierre-Yves David, its main developer. I hope it will be useful for you, to assess the future possibilities of Mercurial today. This is not (only) a pun on “obsolete”, the functionality at the core of evolve which allows safe, collaborative history rewriting ☺

A complete 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

Adaptions optimize the model for special needs like maintaining multiple releases1, 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 default2 - except for hotfixes.

(2) on stable you only do hotfixes, merges for release3 and tagging for release. Only maintainers4 touch stable.

(3) you can use arbitrary feature-branches5, 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.6

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

Table of Contents

Practial Actions

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

  • 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 hotfix8: 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 release9: 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.


  1. if you need to maintain multiple very different releases simultanously, see or 10 for adaptions 

  2. default is the default branch. That’s the named branch you use when you don’t explicitely set a branch. Its alias is the empty string, so if no branch is shown in the log (hg log), you’re on the default branch. Thanks to John for asking! 

  3. If you want to release the changes from default in smaller chunks, you can also graft specific changes into a release preparation branch and merge that instead of directly merging default into stable. This can be useful to get real-life testing of the distinct parts. For details see the extension Graft changes into micro-releases

  4. Maintainers are those who do releases, while they do a release. At any other time, they follow the same patterns as everyone else. If the release tasks seem a bit long, keep in mind that you only need them when you do the release. Their goal is to make regular development as easy as possible, so you can tell your non-releasing colleagues “just work on default and everything will be fine”. 

  5. This model does not use bookmarks, because they don’t offer benefits which outweight the cost of introducing another concept: If you use bookmarks for differenciating lines of development, you have to define the canonical revision to clone by setting the @ bookmark. For local work and small features, bookmarks can be used quite well, though, and since this model does not define their use, it also does not limit it.
    Additionally bookmarks could be useful for feature branches, if you use many of them (in that case reusing names is a real danger and not just a rare annoyance) or if you use release branches:
    “What are people working on right now?” → hg bookmarks
    “Which lines of development do we have in the project?” → hg branches 

  6. Those users who want external verification can restrict themselves to the tagged releases - potentially GPG signed by trusted 3rd-party reviewers. GPG signatures are treated like hotfixes: reviewers sign on stable (via hg sign without options) and merge into default. Signing directly on stable reduces the possibility of signing the wrong revision. 

  7. hg pull and hg push to transfer changes and hg merge when you have multiple heads on one branch are implied in the actions: you can use any kind of repository structure and synchronization scheme. The practical actions only assume that you synchronize your repositories with the other contributors at some point. 

  8. Here a hotfix is defined as a fix which must be applied quickly out-of-order, for example to fix a security hole. It prompts a bugfix-release which only contains already stable and tested changes plus the hotfix. 

  9. If your project needs a certain release preparation phase (like translations), then you can simply assign a task branch. Instead of merging to stable, you merge to the task branch, and once the task is done, you merge the task branch to stable. An Example: Assume that you need to update translations before you release anything. (next part: init: you only need this once) When you want to do the first release which needs to be translated, you update to the revision from which you want to make the release and create the “translation” branch: hg update default; hg branch translation; hg commit -m "prepared the translation branch". All translators now update to the translation branch and do the translations. Then you merge it into stable: hg update stable; hg merge translation; hg ci -m "merged translated source for release". After the release you merge stable back into default as usual. (regular releases) If you want to start translating the next time, you just merge the revision to release into the translation branch: hg update translation; hg merge default; hg commit -m "prepared translation branch". Afterwards you merge “translation” into stable and proceed as usual. 

  10. If you want to adapt the model to multiple very distinct releases, simply add multiple release-branches (i.e. release-x). Then hg graft the changes you want to use from default or stable into the releases and merge the releases into stable to ensure that the relationship of their changes to current changes is clear, recorded and will be applied automatically by Mercurial in future merges11. If you use multiple tagged releases, you need to merge the releases into each other in order - starting from the oldest and finishing by merging the most recent one into stable - to record the same information as with release branches. Additionally it is considered impolite to other developers to keep multiple heads in one branch, because with multiple heads other developers do not know the canonical tip of the branch which they should use to make their changes - or in case of stable, which head they should merge to for preparing the next release. That’s why you are likely better off creating a branch per release, if you want to maintain many very different releases for a long time. If you only use tags on stable for releases, you need one merge per maintained release to create a bugfix version of one old release. By adding release branches, you reduce that overhead to one single merge to stable per affected release by stating clearly, that changes to old versions should never affect new versions, except if those changes are explicitely merged into the new versions. If the bugfix affects all releases, release branches require two times as many actions as tagged releases, though: You need to graft the bugfix into every release and merge the release into stable.12 

  11. If for example you want to ignore that change to an old release for new releases, you simply merge the old release into stable and use hg revert --all -r stable before committing the merge. 

  12. A rule of thumb for deciding between tagged releases and release branches is: If you only have a few releases you maintain at the same time, use tagged releases. If you expect that most bugfixes will apply to all releases, starting with some old release, just use tagged releases. If bugfixes will only apply to one release and the current development, use tagged releases and merge hotfixes only to stable. If most bugfixes will only apply to one release and not to the current development, use release branches. 

Creating nice logs with revsets in Mercurial

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.

Mercurial Workflow: Feature seperation via named branches

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.

Learning Mercurial in Workflows

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.

Infocalypse - Make your code survive the information apocalypse

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

Track your scientific scripts with Mercurial

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.1

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


  1. Mercurial is free software for versiontracking: http://mercurial-scm.org 

writing together – collaborative editing is easy

→ 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).

Internet, community cloud foo and control of my own data

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.

A short introduction to Mercurial with TortoiseHG (GNU/Linux and Windows)

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:

Right-click-Menu

workflow concept: automatic trusted group of committers

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

Kurze Einführung in Mercurial mit TortoiseHG (GNU/Linux und Windows)

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:

Rechtsklickmenü

Clone, GNU/Linux:

Klonen

Gentoo live ebuild for Mercurial

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 code collaboration with Mercurial and Freenet

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

Mercurial is a distributed source control management tool.

Mercurial links:
- Mercurial Website.
- bitbucket.org - Easy repository publishing.
- Hg Init - A very nice Mercurial tutorial for newcomers.

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 easily merge your work.

Mercurial for two Programmers who are (mostly) new to SCM

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.

Mercurial vs. Bazaar speedtest clone and log - update: 4 runs with different versions

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.

Mercurial vs. Bazaar speedtest clone and log - update: hg 1.1 vs. bzr 1.10

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.

Mercurial vs. Bazaar speedtest clone and log (unscientific)

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).

Leistungstests und Vergleiche, DVCS: Mercurial (hg) vs. Git vs. Bazaar(bzr), ...

Vergleiche | Comparisions

Es gibt inzwischen einige schöne Vergleiche von verschiedenen verteilten Versionsverwaltungssystemen im Netz, und da ich sie sowieso lese, habe ich hier jetzt eine Linkliste erstellt. There is now a nice collection of comparisions between distributed version tracking systems, and since I read them anyway, I decided to create a list of links.

Englisch

Mercurial vs. GIT, Leistungstest für lokale Operationen

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

Mercurial ist ein verteiltes Versionsverwaltungssystem.

Links zu Mercurial:

- Mercurial Webseite.

Webseiten einfacher aktualisieren mit Mercurial und lftp

-> 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.

Inhalt abgleichen
Willkommen im Weltenwald!



Beliebte Inhalte

sn.1w6.org news