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

Status: RESOLVED FIXED

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

Description

[(not currently active) Ted Mielczarek]

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.)

Comment 1

[Gregory Szorc [:gps]]

Attachment: 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 2

[Gregory Szorc [:gps]]

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

[Dan Minor [:dminor]]

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

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

lgtm

Comment 4

[Gregory Szorc [:gps]]

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

Comment 5

[Gregory Szorc [:gps]]

Deployed.

Bookmarks should now work properly on hg.mozilla.org.