It probably is possible, but a little tricky. You'd have to basically write you own tag
utility (perhaps as a Mercurial extension) to help out with gathering the extra information needed and doing the extra calls to hg tag
. I don't know much about the API when writing an extension, however, so whatever ideas I offer will be based on calling hg
directly with commands.
By default when you commit on the main repository, the subrepositories are committed first. Then it takes the new changeset id for each subrepo and puts them in the .hgsubstate
file in a format like this:
77ba00000fe8e9ca033d97dc07b85a50dd106837 nested
The recursive tagging would need to get the contents of the .hgsubstate
file as it was in the changeset you are tagging in the main repository. You might think of hg revert
, but that would be a bad idea, as it could easily muck up your working directory (hg
doesn't like doing it on .hgsubstate
anyway). Your best bet for that is doing hg export
for that revision and parsing the resulting diff for the +
lines on the .hgsubstate
file.
Then you would take the changset id and subrepo name from each of those in order to call hg -R <subrepopath> tag -r <id> <tag>
. And of course, finally tag the main repo.
There are still potential problems with this, things that you'll have to remain aware of or figure out how to live with. For example: What happens if you've committed on the main repo but not on 1 or more subrepos? Now you've got more than one changeset on the main repo where .hgsubstate
lists the same changeset id on the subrepo. So if you tag both on the main repo, the changeset on the subrepo will have 2 tags.
I'm using TortoisHg 2.0.5 w/ Mercurial 1.8.4. Tagging subrepositories on their own does not produce any need to commit on the main repo, it should mostly work ok.