I see the same issue, it seems like the plugin trips up with the '-'. We can write a script to get the hex revision number from .hgtags to work around this issue. I'll try to write it and post it here.

hexRevision=$(less .hgtags | grep <tag-name> | cut -d ' ' -f1)
hg up $hexRevision

Of course you have to do this in an "Execute shell" step.

I'd say the problem here is that when pulling/cloning with the option --rev XXX the tag XXX is not available in our local clone.
We'd have to clone/pull the whole repository (with all branches/heads) to be sure we have all tags visible on our local clone.
But that should be fairly easy to accomplish.

Yeah, I realized that after some digging but neglected to update the ticket .

The error message is confusing because it makes it seem like Mercurial can't parse the '-' but is just not displaying it correctly. I've reproduced this in Mercurial in isolation so I doubt this is related.

A couple of weeks ago I wrote a blog post about how to do multi-branch builds much like Bamboo does them (http://thereleaseengineer.com/2013/07/01/multi-branch-builds-in-jenkins/) and I point out something that could be potentially a partial solution which is to configure the job to clone the 'tip' tag but that could still be a problem if you want to update to a branch that hasn't been merged to the branch where the tip tag is on.

It would be awesome if this is fixed, thanks!

At first I also thoughed this would be a problem and patched the plugin like this

 
diff -r 3ad454212cdc src/main/java/hudson/plugins/mercurial/MercurialSCM.java
--- a/src/main/java/hudson/plugins/mercurial/MercurialSCM.java	Wed Aug 14 14:45:46 2013 -0400
+++ b/src/main/java/hudson/plugins/mercurial/MercurialSCM.java	Fri Sep 06 13:08:28 2013 +0200
@@ -316,7 +316,6 @@
     private void pull(Launcher launcher, FilePath repository, TaskListener listener, PrintStream output, Node node, String branch) throws IOException, InterruptedException {
         ArgumentListBuilder cmd = findHgExe(node, listener, true);
         cmd.add("pull");
-        cmd.add("--rev", branch);
         PossiblyCachedRepo cachedSource = cachedSource(node, launcher, listener, true);
         if (cachedSource != null) {
             cmd.add(cachedSource.getRepoLocation());
@@ -585,13 +584,11 @@
                 args.add(cachedSource.getRepoLocation());
             } else {
                 args.add("clone");
-                args.add("--rev", toRevision);
                 args.add("--noupdate");
                 args.add(cachedSource.getRepoLocation());
             }
         } else {
             args.add("clone");
-            args.add("--rev", toRevision);
             args.add("--noupdate");
             args.add(source);
         }

But now I'm not so sure this is actually necessary.
Because whenever you try to build a tag you almost certainly already have pulled the changeset with the .hgtags before. So the benefit of my patch is minimal. I'd say tagging a revision on a different branch then the working copy should generally be avoided.

I don't think that would work.

Consider this case:

• You created a branch "new-feature" off default.
• Default is now two changesets ahead of the point where the branch was created.
• Your "new-feature" branch added a couple of changesets and tagged the tip of the branch with "new-feature-v1".
• Default and "new-feature" are unmerged.
• Now your .hgtags in "new-feature" contains "new-feature-v1", but .hgtags on default doesn't contain that tag.
• If Jenkins clones or pulls with 'hg <clone|pull> --rev default http://repository' it will only grab up to the tip of default and all it's predecessors. This would exclude "new-feature" (because they're unmerged).

I believe an approach like this would work in Git but not in Mercurial.

I think this fix would work. HOWEVER, one of the potential benefits of cloning only the specified branch is that you minimize the size of the repository (in terms of disk space), but maybe this could be an optional flag?

I am thought of this scenario, but considered it not that common in the "real world".
It is continues integration and tags are not that "continues" are they

Of course I am aware that cloning the whole repo will cost more disk space
But after think a bit more about this, my position now is, even if it is uncommon the repository should clone/pull the whole repo despite the disk usage. (disks are cheap)
Building tags should work out of the box or you should explicitly mention in the description of the configuration option that tags won't work.

I agree that tags are not "continuous" but they serve another purpose that still applies in certain scenarios. I think they are still pretty common.

I'm not clear on whether you think if this will be a good feature or not, though. Is your position now that your patch will fix this problem AND it will be valuable?

I implemented an option to clone/pull the whole repo
https://github.com/domruf/mercurial-plugin

Awesome!

Just remember to submit the pull request .

By the way, I found this other pull request that has been there for about two years that tries to fix the same issue (https://github.com/jenkinsci/mercurial-plugin/pull/20). Let's see how your pull request goes