It would be very useful to be able to build specific revisions of a named branch which was forked off of the repository default branch.

If you specify a revision, there is no meaning to the branch parameter.

Anyway for now there is intentionally no support for specifying a tag or other fixed revision, since then there would be no polling, updating, or changelog calculation.

Correct me if I'm wrong Paul, but I believe we already solved this problem.

Our use-case is as follows:

1. QA reports a bug in a specific build
2. Hudson doesn't have this build available (maybe it got deleted because it was too old)
3. We go into the Hudson project, "Build Now", type in the revision number we're interested in and Hudson runs "hg update -b <branch> -r <revision>"

We implemented this by hard-coding a branch under: Source Code Management -> Mercurial -> Branch.
We allow users to specify the revision number to build using: "This build is parameterized", name = "revision", default value = "tip"

So by default Hudson always builds branch/tip but when users select "Build Now" they can specify what specific revision to use.

Jesse, does this make sense to you?

Jesse,

Upon further investigation, this is a real issue. I just didn't do a good job explaining the problem.

Our use-case is as follows:

1. We use the branch-per-release branching strategy, meaning we have one named branch per release. Currently we have two active branches: development-1.2.5 and development-1.3.0
2. We are expecting separate Branch and Revision configuration fields that will result in the following command-line: "hg update -b <branch> -r <revision>"
3. We'd hard-code Branch to development-1.2.5 and Revision to "$revision".
4. "$revision" is defined by "This build is parameterized", name = "revision", default value = "tip"
5. Builds triggered by polls would work against development-1.2.5/tip whereas builds triggered by users would work against development-1.2.5/$revision

Please let me know if you see any problem with this.

'hg up -b development-1.2.5 -r tip' doesn't make sense. 'tip' is the most recently committed or pulled changeset, regardless of branch, so these options conflict.

I think what you want is two jobs. One would be set to use branch = development-1.2.5 and poll normally, complete with changelog. It should not be used for user-initiated builds since (at least until JENKINS-3235 is implemented) that would mess up the changelog.

The other would not be parametrized, not use the Hg plugin at all, and simply 'hg clone -r $revision' as part of your build script. It makes no sense for this to have a changelog or polling, so there is little left for the plugin to do.