The problem is the same on the first build. The issued command is :

hg clone --rev ${TAG}

which has the same effect : only the tagged revision, and not the one containing the tags, is retrieved.

I suggest :

$ hg clone --noupdate REPO TARGET
$ hg update --rev TAG

Regards

Christophe

This field was never intended for use with tags. Various aspects of the Hudson control flow make no sense if the revision is a tag; for example, changelog calculation and polling should probably be skipped entirely, since a tag is normally immutable once created.

(Yes you can move a tag in Mercurial - but you would also need to decide on a branch holding the tag move commits. In other words, different branches can assign a tag of the same name to different revisions. Supporting such scenarios in the Hudson GUI is likely to be overkill when you can more easily run shell commands as part of the build to update your workspace to exactly what you want; changelogs and polling are what make this approach undesirable for regular situations.)

Probably the user will have to indicate a tag in a separate field (mutually exclusive), or check a box saying that the branch field should be treated as a tag.

I get your point, and the behavior you propose makes sense. The changelog calculation should indeed be slipped entirely.

As far a using shell commands as part of the build, the major problem is that hudson won't know what revision we actually build from. Moreover, it would require an additionnal pull since the tag might not be on the pulled branch.

Do you think the solution you propose is easy to implement ? And when do you think it would be ready for use (if at all) ?

Thanks,

Christophe

I have no current plans to work on it.

"Hudson won't know what revision we actually build from" - true but this ordinarily only matters for purposes of changelog display and polling, which would be disabled for a tag-based job anyway.

"it would require an additional pull since the tag might not be on the pulled branch" - if this is the case then there is little hope of a GUI configuration working for you. You would need to write a shell script to the effect of:

hg pull -r branch-which-defines-tags $remote
hg up -c branch-which-defines-tags
hg pull -r $desired-tag remote
hg up -c desired-tag

I do not know of any repository "in the wild" which uses this style, and it is not clear Mercurial even makes it possible. According to

http://hgbook.red-bean.com/read/managing-releases-and-branchy-development.html#id384894

"when Mercurial is parsing the tags in a repository, it never reads the working copy of the .hgtags file. Instead, it reads the most recently committed revision of the file."

where by "most recently committed revision" I understand "tip". If you have multiple heads in the repository (such as multiple branches), then it is impractical to control what tip happens to be.

In my experiments using Hg 1.4.2, the behavior is not even this; after adding a tag on one branch, and setting it (-f) to something else on another branch, the second definition is always used - even if the working copy is updated to the first branch, .hgtags has been more recently edited & committed on the first branch, and .hg/tags.cache has been deleted.

This just started biting us as well and I wanted to add our use case in hope of getting a fix.

We setup two projects in Hudson, development and release. Our development project polls the Mercurial repo and builds from tip. This project works fine as-is since no tags are involved. However, our release project is parameterized to build the tagged version.

For some time now we've worked around the problem by including the variable in the repository URL like this:

https://myrepo.com/mercurial/mysite/#${BUILD_LABEL}

The problem with this approach is the Mercurial plug-in sees each build as a unique URL and does a full clone. That changes every file timestamp every time a build is performed. For our sites it's preferable to see different timestamps depending on when files were updated.

I can get closer to the desired behavior by putting the parameter in the branch field but then I get the problem above. The best I've been able to do is pass a revision hash to the parameter in place of the tag associated with it. But that process is more error prone than communicating tag names.

Hope all that makes sense. Thanks for your work on this plugin!