Linux HA has switched over to Mercurial as our source code management system.
The webinterface for mercurial is available at http://hg.linux-ha.org/.
hg clone http://hg.linux-ha.org/dev
See http://hg.linux-ha.org/ for list of available branches.
found in OSDL bugzilla 1443. http://www.osdl.org/developer_bugzilla/show_bug.cgi?id=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.
"Named" branching is achieved by cloning an existing repository:
hg clone old-branch-name new-branch-name
For more information on CVS concepts and how they apply in Hg, see:
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).
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...
The project will publish three repositories for the latest series:
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.
The only time "testing" should be updated directly is when there is a critical fix during a "code freeze"
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 = email@example.com from = Junior Newhire <firstname.lastname@example.org> [ui] username = Junior Newhire <email@example.com>
to make sure you patches show up with the right author lines in the repository.
The Heartbeat version details should be updated to automatically include the UUID that identities the changeset from which it was built.