Checking out the development branch

Make sure Mercurial is installed
Run
```
hg clone http://hg.linux-ha.org/dev
```

See http://hg.linux-ha.org/[2] 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. http://www.osdl.org/developer_bugzilla/show_bug.cgi?id=1443[3] 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

Terminology

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

Get the latest changes for the repository: hg pull
Merge in the new changes: hg merge
Commit the merge: hg commit
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 *.linux-ha.org
     Port 6666
     Compression yes

into your .ssh/config file.

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

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

[email]
cc = newhire@suse.de
from = Junior Newhire <newhire@suse.de>

[ui]
username = Junior Newhire <newhire@suse.de>

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.

References

[1]	http://www.selenic.com/mercurial/
[2]	http://hg.linux-ha.org/
[3]	http://www.osdl.org/developer_bugzilla/show_bug.cgi?id=1443
[4]	http://www.selenic.com/mercurial/wiki/index.cgi/CvsConcepts
[5]	http://www.selenic.com/mercurial/wiki/index.cgi/CvsCommands