| Based on conversations with Lars, Alan, the people that wrote and use Mercurial (Hg) as well as my own experience, I'd like to propose the following "best practices" for it's usage on this project. I'm happy to answer questions and/or provide clarification where needed. Not also that the subject says "DRAFT" and these proposals are my current best effort and not set in stone. Andrew === Terminology 1. 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 2. 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. 3. 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 4. 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" === Published builds The Heartbeat version details should be updated to automatically include the UUID that identities the changeset from which it was built. -- Andrew Beekhof "Would the last person to leave please turn out the enlightenment?" - TISM |
_______________________________________________________ Linux-HA-Dev: [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
