This site is a work in progress — you can help! Please see the Site news for details.

VersionControl

From Linux-HA

Jump to: navigation, search

Contents

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

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/ 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
    • bnc# 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 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...

  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 need to place

 Host *.linux-ha.org
      Port 6666
      Compression yes
      User hg

into your .ssh/config file.

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 are updated to automatically include the UUID that identities the changeset from which it was built.

Personal tools