Closed Bug 553139 Opened 14 years ago Closed 14 years ago

Figure out what to do about CVS_TAG and CVS_TIME with Hg

Categories

(Camino Graveyard :: General, defect)

Product:
Camino Graveyard
Component:
General
Version:
1.9.2 Branch
Platform:
All
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
Camino2.1

People

(Reporter: alqahira, Assigned: alqahira)

References

Details

Attachments

(1 file)

Fix
5.00 KB, patch
stuart.morgan+bugzilla
: superreview+
Details | Diff | Splinter Review 
mento added code to our Makefile to push the tag and build-time into the Info.plist.  We'll need to update those rules to get the tag (and time) from Hg, and we should probably add GECKO_CHANGESET and CAMINO_CHANGESET, too.
We may also need to update our platform.ini file generation to include the sourcestamp.
(In reply to comment #1)
> We may also need to update our platform.ini file generation to include the
> sourcestamp.

More specifically, our rule http://hg.mozilla.org/users/alqahira_ardisson.org/camino-1.9.2-test/file/3d797c134820/Makefile.in#l344 does not do anything any more, I think, since the file exists (from the forced toolkit/xre build) and since its dependencies are older than it when we get to the Camino build (and they always will be, since xre will always be built first).
I mentioned in my notes on the wiki that we should consider putting our changeset in about:buildconfig, too.

To do that, we'd either have to fork buildconfig.html and include most of the toolkit/content Makefile in pinstripe's Makefile, or unpack buildconfig.html from the jar, run a really fun sed on it, and repack.

The former means we'd have to do changeset info generation twice, in two different makefiles; the latter is scarier, but we'd only have to do it once.

Not sure I want to tackle that in this bug, but I've been thinking about it while thinking about this bug.
Well :P

In Mercurial, when you tag something, the tag gets stored in the subsequent revision, so when you pull a tag, it won't know that it's a tag.  As a consequence, we can't ever put a release tag in the plist in release builds (though we could put the minibranch on which it occurred), which really sucks.

The branchname is always going to be "default" (except on a minibranch, and I have no idea if that branchname persists when pulling by a tag that was based on the minibranch), so we have no real way of getting a branchname like we used to get.

Here's the possible values for MozillaCVSTag in the old system:

               2.0.x                   2.1.x
Nightly:   CAMINO_2_0_BRANCH      HEAD
Release:   CAMINO_2_0_2_RELEASE   CAMINO_2_1_A1_RELEASE

(There's also a possible MozillaCVSTag-has-been-removed "value" in the event a CVS tag/branch can't be determined, as is the case right now in our own 2.1a1pre-M1.9.2 builds.)

In the new world, I guess what we want to do is replace MozillaCVSTag with four keys: MozillaHgRepository, MozillaHgChangeset, CaminoHgRepository, CaminoHgChangeset (or the like), which get us the right repo name ("branch") and changeset, which is as close as we can come to a definitive "tag".
Actually, I realized tinderbox knows the tag because the release tinder-config.pl contains the tag as a variable, and as long as that gets exported, then we can still set the release tag on release builds (just as tinderbox knows MOZ_CO_DATE and MozillaCVSTime only gets sets on tinderbox builds).

One other thing: no one building from a tarball will get *anything* anymore, since the tarball won't contain the .hg repos that have changeset and repo info, nor will they be a tinderbox with access to tag via config info.
Er, I am actually sort-of working on this one, off and on.  I have some patches that implement the two repo+changeset keys, except for a nasty trailing space that I can't make go away when normalizing the URL.
Assignee: nobody → alqahira
Status: NEW → ASSIGNED
Spun the new repo+changeset keys, and the platform.ini removal (comment 1/2), off into bug 562863.

about:buildconfig (comment 3) can move to another bug; Ted has a sort-of half-patch somewhere that makes doing that "less hard" and "less hacky" but it's mostly geared towards comm-central, which has two sets of configure arguments, etc.  All we want to do is insert a link right under the platform changeset link, because that's all we need there, and a sed hack would probably work.
Summary: Fix CVS_TAG, CVS_TIME for Hg (and add changeset info) → Figure out what to do about CVS_TAG and CVS_TIME with Hg
So is there anything left here other than ripping out the CVS stuff?
I still want to see if we can pull the tag in via info Tinderbox knows (comment 5), converting CVS_TAG into HG_TAG; CVS_TIME is superfluous and can be removed, though.
Attached patch Fix — — Splinter Review 
This replaces CVS_TAG with HG_TAG and gets rid of the superfluous MOZ_CO_DATE-based CVS_TIME; HG_TAG will work in conjunction with changes to madhatter that export the tag/branch (if exists) to the environment, similar to how MOZ_CO_TIME was (is) exported.

In practical terms, it means our release builds will continue to get a CAMINO_2_1_A1_RELEASE tag stored in their plist (but no other builds will have a tag stored).
Attachment #504067 - Flags: superreview?(stuart.morgan+bugzilla)
Comment on attachment 504067 [details] [diff] [review]
Fix

sr=smorgan
Attachment #504067 - Flags: superreview?(stuart.morgan+bugzilla) → superreview+
http://hg.mozilla.org/camino/rev/5794c993f355
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: