This also affects triggering on changes, especially when we perform merges. If there's no change to the default (or specified) branch then the job is not triggered. We would like to trigger on changes to any branch.

Are you sure you do not want to use the Multiple SCMs Plugin for this use case?

The Multiple SCM plugin exists to handle more than one repository. Also as expressed by the author different repositories should be checked out to their own subfolders to not cause conflicts. In our case we have only a single repository which contains named branches. Each branch contains tests for a specific version of the application under test. Some tests require a hotswap between those branches. Given that all branches of that given single repository have to be checked out. So we really miss the trigger as Dave mentioned.

Dave's reported case sounds a lot like the caching feature built in to the plugin, which would not require a special job or Copy Artifact - you just configure your Hg installation to use caching, and then any job using a given public repo location will automatically share the cache (and slaves do not need to make the remote connection). If you are trying to do something more subtle, such as archiving particular snapshots of the repository, then I guess a freeform build step with hg clone -U would be suitable, but I am not sure what trigger to use; the Mercurial plugin is designed to maintain a checkout of a particular branch and poll for changes in it, which is a quite different use case. You would really want a custom build trigger which just looked for activity of any kind in a given repo.

Henrik's case is different and probably suited to Multiple SCMs - place a checkout of each named branch in its own subdirectory of the workspace. Each branch will be polled for changes. That ought to work fine with the current Mercurial plugin unless I am missing something.

jglick, Dave and myself are working on the same project. So I have just added more details to our problem. As I have mentioned we can't have multiple subdirectories (checkouts) of the repository because the build process has to be able to do a hotswap between branches. That means all named branches of the local clone have to be up-to-date.

The shell build step at the start of the job to run hg pull seems like the right solution for you then. Does this break anything?

That's how I do it - I'm using hg plugin to get data into fake directory (to get at least some changes in build description) and after that getting everything from hg manually. It's working but it's ugly hack - it will be much better if hg plugin could get everything.

I had been looking for this feature for a while and I discovered that the shared repository feature accomplishes what I wanted.

Normally, jobs using the mercurial plugin would first attempt to clone the repo with hg clone --rev [REV] <remote_repo> but now, it seems to attempt to clone the repo in the shared location or clone from it if it already exists.

With this, you no longer need to set up separate jobs to clone/build/package/etc. multiple branches. It also helps on a very specific corner case where Mercurial can't update to changesets tagged in a branch that's not the cloned one. This may be specific to my particular repository, and may not be a general use case, but it does help.

Now, on the other hand, I can understand how in certain cases, one might not want to share a repository and needs a full clone in the local workspace only, for instance if Jenkins is merging/committing code and it may collide with other jobs using the shared repo, so providing the option to clone all branches would help in that case.

After rereading the original request I think this is out of scope for the Mercurial plugin, which is designed around providing an SCM implementation with a checkout/update of a specific branch and a corresponding trigger/changelog/etc. What is being requested is really a distinct plugin, which may or may not want to depend on mercurial-plugin for some low-level functions: a Trigger combined with something else such as a Publisher which looks for any new changesets in a specified repository and produces a bundle as an artifact.