We upgraded Mercurial on our linux machines (the ones known as moz2) from v0.9.5 to 1.1.2, which changes what |hg clone -r <tag>| does when <tag> has been moved. Here's the low-down for the record. Suppose you have an example repository like this: changeset: 3:d5d4d71fcd5f summary: Added tag THE_TAG for changeset a151678ac56a changeset: 2:a151678ac56a summary: second file rev changeset: 1:561e194d6b5c summary: Added tag THE_TAG for changeset 32b7aa090489 changeset: 0:32b7aa090489 summary: first file rev Changeset 3 is moving the tag to a later revision of the single file in our repo. With 1.1 or later, when you do hg clone -r THE_TAG ... it has some tipmost algorithm for resolving THE_TAG to 2:a151678ac56a, and pulls in only changesets up to that for the working dir. Then it does an update to THE_TAG, but the .hgtags checkout has that pointing to 32b7aa090489 and you get updated to the first rev in our example. Intuitive eh ? If you hg clone ...; hg up -r THE_TAG then it pulls in all the changesets and .hgtags is up to date, so you get 2:a151678ac56a in the end. Prior to 1.1 both methods give you 2:a151678ac56a on ident, apparently because there is an implicit 'hg up -r tip' inside hg clone. Why is this a problem ? patcher2.pl uses 'hg clone -r UPDATE_PACKAGING_R6' when running it's BuildTools function (a very convoluted way to get hold of the mar & mbsdiff utilities, and tools/update-packaging). That tag moved from f197b51bbc29a30860e750ee87fd0a047a024f2e to d7d64f68423b68a671f623f123e90057ebc49dac to pick up support for the release-layout of files. We end up with f197... and try to build updates with that release layout, it blows up, unhappiness results. Luckily, the fix is shorter than this comment.

Updates after the initial clone. Also generalizes the hg repository var.

Comment on attachment 358816 [details] [diff] [review] Clone then update Looks good!

Also updates the ReleaseUpdatesFactory for the env var change. Checking in patcher/patcher2.pl; /cvsroot/mozilla/tools/patcher/patcher2.pl,v <-- patcher2.pl new revision: 1.37; previous revision: 1.36 done Checking in buildbotcustom/process/factory.py; /cvsroot/mozilla/tools/buildbotcustom/process/factory.py,v <-- factory.py new revision: 1.83; previous revision: 1.82 done

I've created UPDATE_PACKAGING_R7 in CVS using the equivalent of bug 420947 comment 17. Compared to R6, the only change that will actually get used is patcher/patcher2.pl - rev 1.36 to 1.37 (the change in this bug) FTR, also modified are tools/update-packaging make_incremental_update.sh - rev 1.12 to 1.13 (nightly updates, bug 470811) make_incremental_updates.py -rev 1.8 to 1.9 (bug 454261, but this isn't the copy we use generating release updates) and several files in tools/release, which we pull from another tag for 2.0 and 3.0 releases. Nothing changed in tools/release/MozBuild that patcher2 does use. I've also created a UPDATE_PACKAGING_R7 tag in mozilla-central and mozilla-1.9.1 at the same point as _R6. And tagged build/tools at http://hg.mozilla.org/build/tools/rev/cf6614a8d619 AFAICT there are no changes to the scripts for patcher and update-verify config-bumps since _R6.