This site best when viewed with a modern standards-compliant browser. We recommend Firefox Get Firefox!.

Linux-HA project logo
Providing Open Source High-Availability Software for Linux and other OSes since 1999.

USA Flag UK Flag

Japanese Flag


About Us

Contact Us

Legal Info

How To Contribute

Security Issues

This web page is no longer maintained. Information presented here exists only to avoid breaking historical links.
The Project stays maintained, and lives on: see the Linux-HA Reference Documentation.
To get rid of this notice, you may want to browse the old wiki instead.

1 February 2010 Hearbeat 3.0.2 released see the Release Notes

18 January 2009 Pacemaker 1.0.7 released see the Release Notes

16 November 2009 LINBIT new Heartbeat Steward see the Announcement

Last site update:
2022-11-28 03:47:31

Linux HA has switched over to Mercurial as our source code management system.

The webinterface for mercurial is available at

Checking out the development branch

  • Make sure Mercurial is installed
  • Run

    hg clone

See for list of available branches.

Recommended Hg/bugzilla policy

  • Most or all commits should have associated bugzillas. If you don't have a bugzilla for at least 90% of your commits, you should make more bugzillas. 100% is the desired outcome.
  • For each commit associated with a bugzilla, the bug number should appear in the first line in a style something like this:
    • OSDL # 1234 blah blah blah
    • Novell # 183216 blah blah blah blah
    • LTC # 24752 blah blah blah blah
  • For each bug which has been marked as fixed, the changeset submitted to -dev should be indicated by URL. An example of what I mean can be

    found in OSDL bugzilla 1443. Note that in this case, it took me two changesets to really resolve the bug. Both are indicated in the bugzilla. This bug doesn't follow my suggested guidelines perfectly - in the 2nd changeset it just says "Bugzilla 1443" instead of "OSDL 1443". The appearance of the # sign would also be an improvement, I think...

In an ideal world these things could be followed consistently enough that one could write a tool that given any changeset could find the bugzilla for it and vice versa. But, failing that, it would be good if humans could do it quickly and easily.

Mercurial best practices


  • Hg branch != CVS branch Hg has branching (a lot of it in fact) but unlike CVS they are unnamed.

    "Named" branching is achieved by cloning an existing repository:

    hg clone old-branch-name new-branch-name
  • Hg head != CVS HEAD The last commit to a Hg branch is called the "head" of that branch. There is no concept of a trunk in Hg.
  • Hg "tip" != CVS "HEAD" In Hg, the last head to be updated is given the special "tip" alias. A common mistake is to think that the repository's tip is the same as HEAD in CVS
  • Hg tag == CVS tag Enough said

For more information on CVS concepts and how they apply in Hg, see:

One repository per CVS-style branch.

That this is the method advocated by the Hg developers, I think that counts as a pretty good reason on its own. Plus given the reality that locally (with CVS) you end up with one directory per branch anyway, nothing much will change (in Heartbeat's case) except for an extra few megabytes on the server. Its also a little easier to avoid making changes to the wrong "branch"

The project will create a repository for every X.Y series with releases (X.Y.Z) marked as tags (much like they are now).

One "head" per published repository

Given that repositories do not support named heads, determining what head should be used at a given point is a non-trivial problem. As such, all _published_ repositories should contain exactly one head to make it obvious. To help enforce this "hg push" aborts and does not publish additional heads by default.

Publishing additional per-feature repositories is an option here for those working on multiple things at once. As is having as many heads as you like until you're ready to make the changes available.

If "hg push" complains...

  1. Get the latest changes for the repository: hg pull
  2. Merge in the new changes: hg merge
  3. Commit the merge: hg commit
  4. Push your changes: hg push

Official Repositories

The project will publish three repositories for the latest series:

  • working
  • testing
  • stable

Using the "push" method, current CVS committers will be able to update the "working" repository. This repository will never be frozen and is always available for updates.

The second repository "testing" will be kept in sync with "working" automatically (either with a cron job or Hg hooks) except when a release is due.

During a release period only updates critical to the release will be allowed to "testing".

Once the build is validated and we are ready for release, "testing" will be tagged and pushed to "stable" where it will remain almost always unaltered.

Where to make changes

  • Regular development should be done in "working"
  • Regular bug fixes that can be picked up in the next release should be made in "working"
  • Critical fixes should be made in "stable" and merged back into "working" (using pull) These should be exceedingly rare and will probably be a trigger for the project to make a minor point release

The only time "testing" should be updated directly is when there is a critical fix during a "code freeze"

Initial set-up for developers

In your local environment you probably need to place

Host *
     Port 6666
     Compression yes

into your .ssh/config file.

Then on your account at you need to set up various things with the /home/linux-ha/hg/share/ script.

In your .hgrc file, you will want to put a customized version of

cc =
from = Junior Newhire <>

username = Junior Newhire <>

to make sure you patches show up with the right author lines in the repository.

Published builds

The Heartbeat version details should be updated to automatically include the UUID that identities the changeset from which it was built.