Pushing an evolve'd bookmark leads to odd bookmark state on the webheads

RESOLVED FIXED

Status

Developer Services
Mercurial: hg.mozilla.org
RESOLVED FIXED
2 years ago
2 years ago

People

(Reporter: ted, Assigned: gps)

Tracking

Details

MozReview Requests

Submitter Diff Changes Open Issues Last Updated
Loading...
Error loading review requests:

Attachments

(1 attachment)

(Reporter)

Description

2 years ago
I had pushed a bookmark (ios) to http://hg.mozilla.org/users/tmielczarek_mozilla.com/gecko-ios/, and then did some work locally, evolved some changesets, and pushed the bookmark again (pointing at a new changeset).

After the second push, the repo on hg.mo showed the bookmark pointing at the first changeset, and then a second bookmark (ios@default) pointing at the new changeset.

gps says he thinks this is from our mirroring setup. (Also he already fixed the problem in this repo.)
(Assignee)

Comment 1

2 years ago
Created attachment 8683210 [details]
MozReview Request: hgmo: replace bookmarks when replicating (bug 1139056); r?dminor

hgmo: replace bookmarks when replicating (bug 1139056); r?dminor

Currently, the mirroring logic performs a `hg pull`. The default
behavior of `hg pull` w.r.t. bookmarks is somewhat complicated. If a
bookmark was not fast-forwarded, it is diverged. There is currently no
knob in Mercurial to change this behavior (although remotenames will add
it eventually). This results in bookmarks like "@default" appearing and
the bookmark state on hgweb machines getting out of sync with the
master.

This commit introduces a wrapping of the bookmarks function in the hgmo
extension. When the "hgmo.replacebookmarks" config flag is set, we
replace the built-in updating logic with a simple "replace from remote"
scheme.

We modify our replication script on the hgweb machines to define this
config flag when performing `hg pull`. As a result, we no longer have
bookmark divergence on hgweb machines and bookmarks work as they should.

A test demonstrating old, incorrect behavior has been modified to
reflect the new, proper behavior. New tests verifying that bookmark
deletion work have been added.
Attachment #8683210 - Flags: review?(dminor)
(Assignee)

Comment 2

2 years ago
Comment on attachment 8683210 [details]
MozReview Request: hgmo: replace bookmarks when replicating (bug 1139056); r?dminor

hgmo: replace bookmarks when replicating (bug 1139056); r?dminor

Currently, the mirroring logic performs a `hg pull`. The default
behavior of `hg pull` w.r.t. bookmarks is somewhat complicated. If a
bookmark was not fast-forwarded, it is diverged. There is currently no
knob in Mercurial to change this behavior (although remotenames will add
it eventually). This results in bookmarks like "@default" appearing and
the bookmark state on hgweb machines getting out of sync with the
master.

This commit introduces a wrapping of the bookmarks function in the hgmo
extension. When the "hgmo.replacebookmarks" config flag is set, we
replace the built-in updating logic with a simple "replace from remote"
scheme.

We modify our replication script on the hgweb machines to define this
config flag when performing `hg pull`. As a result, we no longer have
bookmark divergence on hgweb machines and bookmarks work as they should.

A test demonstrating old, incorrect behavior has been modified to
reflect the new, proper behavior. New tests verifying that bookmark
deletion work have been added.

Comment 3

2 years ago
Comment on attachment 8683210 [details]
MozReview Request: hgmo: replace bookmarks when replicating (bug 1139056); r?dminor

https://reviewboard.mozilla.org/r/24225/#review21731

lgtm
Attachment #8683210 - Flags: review?(dminor) → review+
(Assignee)

Comment 4

2 years ago
https://hg.mozilla.org/hgcustom/version-control-tools/rev/ff661fd7a040d3b139a06c3f738d25bc362cc0b6
hgmo: replace bookmarks when replicating (bug 1139056); r=dminor
(Assignee)

Comment 5

2 years ago
Deployed.

Bookmarks should now work properly on hg.mozilla.org.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → FIXED
(Assignee)

Updated

2 years ago
Assignee: nobody → gps
You need to log in before you can comment on or make changes to this bug.