1473502 - f839685ceb8eebc50fa69c9273141a4bdc8ce1e2 missing in the hg -> git map

Status: RESOLVED FIXED

(Developer Services :: Git, enhancement)

Description

[Marco Castelluccio [:marco]]

https://mapper.mozilla-releng.net/gecko-dev/rev/hg/f839685ceb8eebc50fa69c9273141a4bdc8ce1e2

Failing code coverage task: https://tools.taskcluster.net/groups/ZaPjMcTpQji_h8vBQWsASA/tasks/ZaPjMcTpQji_h8vBQWsASA/details.

Dave, can you force the remapping?

Comment 1

[Marco Castelluccio [:marco]]

(In reply to Marco Castelluccio [:marco] from comment #0)
> Failing code coverage task:
> https://tools.taskcluster.net/groups/ZaPjMcTpQji_h8vBQWsASA/tasks/
> ZaPjMcTpQji_h8vBQWsASA/details.

Also https://tools.taskcluster.net/groups/ZVvJGoafSbimQkzH_BhMog/tasks/ZVvJGoafSbimQkzH_BhMog/details.

Comment 2

[:dhouse]

I pushed the mapping:

Found the converted commit in gecko-dev. The commit is from 5 months ago. So it was old enough to not be caught by the mapping check.

```
$ grep f839685ceb8eebc50fa69c9273141a4bdc8ce1e2 ./vcssync1/build/conversion/beagle/.hg/git-mapfile
4f6c8c85c1212a026db5f8b070dd03ba954ce097 f839685ceb8eebc50fa69c9273141a4bdc8ce1e2
```

https://hg.mozilla.org/mozilla-central/rev/f839685ceb8eebc50fa69c9273141a4bdc8ce1e2
"""
Bug 1403027 - Do not throw from PerformanceObserver.observe when none of the entryTypes are known (log a JS console warning instead); r=bz MozReview-Commit-ID: Lx2cjWDX8sh
"""

https://github.com/mozilla/gecko-dev/commit/4f6c8c85c1212a026db5f8b070dd03ba954ce097
"""
 Bug 1403027 - Do not throw from PerformanceObserver.observe when none…

… of the entryTypes are known (log a JS console warning instead); r=bz

MozReview-Commit-ID: Lx2cjWDX8sh

--HG--
extra : rebase_source : 0305286f0fde08356c72acc71fb6095238270ead

"""

Comment 3

[:dhouse]

I'm increasing the mapping check to scan for half a year hourly, and a full year twice daily, and 5 years once a month.

That would have caught this mapping within the hour, and if it had gone another month before going into master then the new cron schedule would catch it within 12 hours.

The previous hourly scan was taking 2-3 minutes. Timing the new (6 months window) one shows 7 minutes and it used less than 30s cpu time. So I think that is acceptable and will not take needed resources from the conversion processes.