|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
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.