475309 - [Fx3.1] release update generation is broken

Status: RESOLVED FIXED

(Release Engineering :: General, defect, P1)

Description

[Nick Thomas [:nthomas] (UTC+12)]

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.

Comment 1

[Nick Thomas [:nthomas] (UTC+12)]

Attachment: Clone then update

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

Comment 2

[[e-mail] (:bhearsum)]

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

Looks good!

Comment 3

[Nick Thomas [:nthomas] (UTC+12)]

Attachment: Patch as committed

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

Comment 4

[Nick Thomas [:nthomas] (UTC+12)]

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.