1490244 - Overlaying inbound onto unified is often slow

Status: RESOLVED DUPLICATE of bug 1480203

(Developer Services :: Mercurial: hg.mozilla.org, defect)

Description

[Andreas Tolfsen ❲:ato❳]

Sorry if this is not the right place to file this, and doubly-sorry
that this is more of a feature request than a bug.

My experience working with mozilla-unified is that the bookmarks
are slow to update when you push to mozilla-inbound.  If you use
the inbound bookmark on mozilla-unified to track the tip of inbound,
it is more often than not rather slow at updating (often several
minutes).

This makes it hard to rebase and push multiple patches in sequence
to inbound, which is a thing I do frequently.

Comment 1

[Connor Sheehan [:sheehan]]

(In reply to Andreas Tolfsen ❲:ato❳ from comment #0)
> Sorry if this is not the right place to file this, and doubly-sorry
> that this is more of a feature request than a bug.

No need to apologize! This is likely the most accurate component
to file against for mozilla-unified. Feature requests are perfectly
acceptable, and I'd even encourage developers to file them IMO.


> My experience working with mozilla-unified is that the bookmarks
> are slow to update when you push to mozilla-inbound.  If you use
> the inbound bookmark on mozilla-unified to track the tip of inbound,
> it is more often than not rather slow at updating (often several
> minutes).
> 
> This makes it hard to rebase and push multiple patches in sequence
> to inbound, which is a thing I do frequently.

There are a few reasons why bookmark updates for inbound would be slow
in unified. The first is due to the way we are pulling the independent
firefox repos together into unified. At the moment we run a daemon
which executes the `hg unifyrepo` command every 30 seconds. So if you make
a push immediately after a repo unification completes, you will have to wait
at least 30 seconds before seeing the changeset in unified. The second reason
is a known race condition in the `hg unifyrepo` command. Due to this race
condition the unification command consistently fails near the end of completion
and mozilla-unified is not updated from the unification staging repository.
The daemon is set up to immediately retry on failure, but the race condition
may manifest itself again and the command might need to be run a few times before
completing successfully.

We have bugs on file for both of these known issues (bug 1488455 and bug 1480203)
and plans to mitigate them in the future. Essentially we will 1) trigger repo
unification on push to a source repository and 2) fix the race condition.
The only thing stopping us from doing right now so is other work. :) 

So, I'm going to mark this as a duplicate of the race condition bug (likely
the main issue with bookmark update speed). If you have any follow up info
or comments feel free to re-open.

Comment 2

[Andreas Tolfsen ❲:ato❳]

Thanks, I’m glad this is already on your radar!

I also wonder if there are any plans to “unify” on interaction
against the mozilla-unified repo?  Might this problem not go away
if existing tooling was made to work against a single repo, instead
of having to overlay inbound into unified?

Comment 3

[Gregory Szorc [:gps]]

Yes, the long-term plan is to push to mozilla-unified and make the other repos derived from it for backwards compatibility. This requires significant changes to how we go about managing the Firefox repos. It is on the radar of a few people but it isn't high priority.