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.

I think the understanding is that you should only tag upstream of the revision you're tagging, then it becomes impossible to merge in a .hgtags file that refers to changesets that the merge didn't drag along with the .hgtags file.
–
Lasse V. KarlsenFeb 22 '11 at 16:14

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.

Let's say in changeset a1 we added a file. Now in the merged repository if you update the repo to 1.01, will that include the new file added in a1? I would have thought it would have included that file.. which is not what we want..
–
MarcusFeb 22 '11 at 18:18

@Marcus 1.01 is below the merge, since they are in separate branches it won't be included.
–
msarchetFeb 22 '11 at 18:35

I am referring to after the merge.. When you merge A & B we would merge .hgtags so it would include the 1.01 tag.
–
MarcusFeb 22 '11 at 18:59

1

@Marcus, if you merge and are working off of a changeset above the merge then all of the code is there. However by moving below the merge to the tagged changeset you are changing the code to look like the tag was when it was created. Does that make sense
–
msarchetFeb 23 '11 at 15:04