Question

If you are merging changes from repository B into repository A should you merge changes in .hgtags?

Repository B could have had tags 1.01, 1.02, 1.03 which are not in A. Why would you ever merge those into repository A's .hgtags file? If we merged and then tried to view repository A by looking at tag 1.01, I would think this wouldn't work.

Was it helpful?

Solution

Short Answer: This does work properly and you should merge .hgtags

Why should you actually merge .hgtags and why does it make sense?

So you have

  • Repo A with Changesets 3 (a1), 4 (a2), 5 (a3)
  • Repo B with Changesets 3 (b1), 4 (b2), 5 (b3) tag 1.01

The above is listed as the Changeset Number (long unique hex id) tag

So you merge repo B into Repo A and get something that looks like.

      9 (a4) merge 
     /   \
    |   8 (b3) tag 1.01
    |    |
    |   7 (b2)
    |    |
    |   6 (b1)
 5 (a3)  |
    |    |
 4 (a2)  |
    |    |
 3 (a1)  |
     \   /
     2 (a0) 

If you update the repo to tag 1.01 you will get exactly what the code looked like at that point in time When it was in Repo B just as mercurial promises.

You should merge them as the changesets from Repo B that were tagged are now part of the changeset tree in Repo A, so therefore the changesets you tagged in Repo B are now tagged in Repo A. Not merging them would just cause you to lose the tags that you created for the changesets.

OTHER TIPS

An interesting thing to know (from the mercurial wiki)

The 'effective' tags are taken from the .hgtags files on the heads of all branches. Tags closest to tip take precedence.

So when you merge (combine two heads), you need to merge the .hgtags or some tags will disappear.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top