Firefoxtree extension doesn't recognize comm-esr102, mozilla-esr102
Categories
(Developer Services :: Mercurial: firefoxtree, defect)
Tracking
(Not tracked)
People
(Reporter: rjl, Assigned: sheehan)
Details
Attachments
(1 file)
I updated to rev 03b4015983d4 of version-control-tools and have the firefoxtree extension enabled. Existing repos (comm-esr91, comm-beta, mozilla-esr91, etc) work as expected.
STR:
- Clone comm-central
hg clone comm fxtree_test - chdir into the repository
- Pull comm-esr102
hg pull comm-esr102
Expected:
Mercurial will pull in from the comm-esr102 repository.
Actual:
- Error:
abort: repository comm-esr102 not found
This happens with using mozilla-central/mozilla-esr102 as well.
Pulling using the full URL works. Doing so updates .hg/firefoxtrees.
comm a5da4c3f4345256601f2a48479db37c8384899ce
comm-esr10 f81fcbcfce4186eb9b069b0b5fb054c00019231f
The revision shown for comm-esr10 is the current tip of comm-esr102 oh hg.mo. Somewhere along the line the 3rd digit is being truncated.
I think its in mozautomation.repository.resolve_uri_to_tree(). Those uri.startswith calls look suspect.
Given a uri "https://hg.mozilla.org/releases/comm-esr102", looping through REPOS will reach "comm-esr10" and match before "comm-esr102" is reached.
|
Assignee | |
Updated•3 years ago
|
|
|
Assignee | |
Comment 1•3 years ago
|
||
I see the latter issue of truncated fxhead tag, but not the abort: repository comm-esr102 not found error:
❯ hg clone https://hg.mozilla.org/comm-central comm-central-test
applying clone bundle from https://hg.cdn.mozilla.net/comm-central/b23afa595fe07e553b781e57f643bfb5d4a18f01.zstd-max.hg
adding changesets
adding manifests
adding file changes
added 35680 changesets with 177432 changes to 26699 files
finished applying clone bundle
searching for changes
adding changesets
adding manifests
adding file changes
added 19914 pushes
added 5 changesets with 21 changes to 18 files
new changesets c2a92135b3b8:25de6d52888b
35680 local changesets published
updating to branch default
12694 files updated, 0 files merged, 0 files removed, 0 files unresolved
❯ cd comm-central-test
❯ hg pull comm-esr102
pulling from comm-esr102
searching for changes
adding changesets
adding manifests
adding file changes
added 0 pushes
added 10864 changesets with 8371 changes to 6514 files (+344 heads)
new changesets c79db400bb91:f81fcbcfce41
(run 'hg heads .' to see heads, 'hg merge' to merge)
❯ hg fxheads
35684:25de6d52888b comm Bug 1698391 - Allowing refreshing an OpenPGP key. r=mkmelin
46548:f81fcbcfce41 comm-esr10 Automatic version bump CLOSED TREE NO BUG a=release DONTBUILD
|
|
Assignee | |
Comment 2•3 years ago
|
||
resolve_uri_to_tree takes a URI (ie https://hg.mozilla.org/mozilla-central)
and attempts to resolve it to a known Firefox tree shortname (ie central).
It does so by iterating through the list of known Firefox tree repo names and
building out each potential URI, and then checking if each built URI matches
the passed URI. The matching condition used is uri.startswith, assumedly
so something like https://hg.mozilla.org/mozilla-centra or some other minor
typo results in a match still being found. This has worked without any issue to
date, until esr102 was created. Since the built URIs for esr10 would match
the startswith metric on esr102, passing the URI for esr102 is returning
esr10 as the resolved tree.
Switch resolve_uri_to_tree to return the resolved tree only when the built
URI exactly matches the passed URI. Add a few comments clarifying what the
function is doing and use more descriptive variable names.
Pushed by cosheehan@mozilla.com:
https://hg.mozilla.org/hgcustom/version-control-tools/rev/adc8bddf688b
mozautomation: match built URIs exactly in resolve_uri_to_tree r=zeid
Description
•