Bootstrap complains it is running from an old revision
Categories
(Firefox Build System :: Bootstrap Configuration, defect, P3)
Tracking
(firefox78 fixed)
Tracking | Status | |
---|---|---|
firefox78 | --- | fixed |
People
(Reporter: mossop, Assigned: rstewart)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
(deleted),
text/x-phabricator-request
|
Details |
Just ran mach boostrap and got the following warning:
WARNING! You appear to be running `mach bootstrap` from an old revision.
bootstrap is meant primarily for getting developer environments up-to-date to
build the latest version of tree. Running bootstrap on old revisions may fail
and is not guaranteed to bring your machine to any working state in particular.
Proceed at your own peril.
This is not the case though. I am running it on a draft changeset for a bug I'm working on but the parent of that changeset is the tip of central currently.
Comment 1•5 years ago
|
||
Bugbug thinks this bug should belong to this component, but please revert this change in case of error.
Assignee | ||
Comment 2•5 years ago
|
||
Can you provide a set of steps to repro? I assume this is an hg
thing and I am extremely not an hg
person.
We run hg parent --template {word(0, date|hgdate)}
to get the commit time of HEAD so we'll likely need some alternative that also works for "draft changesets".
Assignee | ||
Updated•5 years ago
|
Comment 3•5 years ago
|
||
I am running it on a draft changeset for a bug I'm working on but the parent of that changeset is the tip of central currently.
Was that changeset rebased, and is it originally old?
Reporter | ||
Comment 4•5 years ago
|
||
(In reply to Ricky Stewart from comment #2)
Can you provide a set of steps to repro? I assume this is an
hg
thing and I am extremely not anhg
person.We run
hg parent --template {word(0, date|hgdate)}
to get the commit time of HEAD so we'll likely need some alternative that also works for "draft changesets".
Ah ok, that is getting the date for the draft changeset, which may be well in the past as it is here where I started working on the patch a while ago.
I would suggest instead running this: hg log --rev "heads(ancestors(.) and not draft())" --template "{word(0, date|hgdate)}"
. This will log the date for the top-most public commit in the current working tree's ancestors.
I think it is worth noting that the commit date is not necessarily the time the commit landed in central. The commit date can be manually set and in a workflow involving evolve the commit date can just be the first date that the patch was worked on. As an example the date for the current tip of mozilla-central has a commit date from three days ago even though it was pushed fifteen minutes ago. Probably not going to cause an issue here in general but worth noting.
Reporter | ||
Updated•5 years ago
|
Assignee | ||
Comment 5•5 years ago
|
||
hg
gives us some additional levers to tweak when determining which commits are public and non-public. All the better, because unlike git
, hg
's default behavior under a rebase is to preserve the original authorship time of the commit, so if you rebase the latest version of central on a month-old commit, you might still get the "revision too old" error despite your tree actually being completely up-to-date. Here we replace the original logic with something a little bit more robust to that scenario.
As before, this is a best-effort check that might have false positives or false negatives; this commit doesn't change that, but hopefully it decreases the amount of false positives under hg
.
Updated•5 years ago
|
Comment 7•5 years ago
|
||
bugherder |
Description
•