1540181 - Make projects/larch non-publishing

Status: RESOLVED FIXED

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

Description

[Connor Sheehan [:sheehan]]

The Necko group is using Larch as a collaborative repository to work on socket process isolation as a team, before landing code to central. They ran into some trouble over in bug 1531583, where they had a stack consisting of changesets landed in central, unlanded in central, and merge commits. It took a decent amount of effort to hg graft out the unlanded code and end with a clean stack of commits.

I spoke with Junior about how his team is using the repo, and we had the following conversation:

sheehan: are changes that your team pushes to larch supposed to be considered finalized?
junior: no, still long way to go
junior: I would say at least months

So really, this team is using the Larch repo as their "draft" repository, and mozilla-central as their "finalized" repository. When they are making pushes to larch, they don't expect them to be permanent (ie in the "published" phase). They expect to rebase them around, make histedit/evolve/absorb style changes, and possibly even remove commits altogether. This is one of evolves main design goals - making this workflow easy and efficient.

I think we should make larch a non-publishing repo, and recommend that this team use this evolve-style workflow to update their tree:

$ hg pull central
$ hg rebase -r <revision hash of first draft commit in stack> -d central
$ hg up tip  # update to new commit
$ hg evolve  # handle any merge issues here
$ hg evolve
$ hg evolve --all  # do this in one command, and stop on merge conflicts
...

This way they don't end up with a new head each time they update their tree to the latest central, and the true intent of the repo is realized. There is more info about the concept of phases at hg help phases, for anyone who is curious. See the section titled "Phases and servers".

If others are on board with this, it may be desirable to make all project repos non-publishing by default, since the intent of most project repos seems to be for use as a group before landing to central.

I've CC'd a few people who I thought might find this interesting or have comments.

Comment 1

[Junior [inactive]]

After bug 1531583, things are going to be easier. Only unlanded patches are on top of central until we land patches to central.

The workflow becomes:

c -- (targeted rebased parent) mozilla-central `default` (changeset B)
|
|
|  l -- larch specific patch_n (changeset A_n)
|  |
|  ?
|  |
|  l -- larch specific patch1 (changeset A1)
| /
|/
c -- a base (parent) changeset which can be found also on m-c
|
|
V

c for changeset in central
l for changeset in larch

1. hg up -r B
2. hg merge --tool=:local -r A_n to create a blind merge commit
3. hg commit -m "merge m-c"
4. hg revert -r B to deal with the add/remove files
5. hg amend

Therefore, we got changeset C is almost identical to changeset B.
('almost' is because hg commit does some clang-format fix)

d   -- merge m-c (changeset C)
|\
| \
c -- (targeted rebased parent) mozilla-central `default` (changeset B)
|  |
|  |
|  l -- larch specific patch_n (changeset A_n)
|  |
|  ?
|  |
|  l -- larch specific patch1 (changeset A1)
| /
|/
c -- a base (parent) changeset which can be found also on m-c
|
|
V

We can start to
hg graft -f A1, fix conflict and go on.
(-f since A1 is an ancestor of C now)

Here's some analysis:
(a) hg merge takes much computer time
I believe it takes >10 hours computer time, for the sake of absorbing the old head. (which draft repo doesn't need)
Maybe there's another way to do a dumb merge without painful merge time.

(b) hg graft is annoying since we need to have a list of changesets to graft.
Absolutely drafting repo can change things to hg rebase
I believe hg rebase for the drafting will ease the painful step.

(c) hg graft means we would have lots of dup changesets which indicates the same change with different base.
It could be good or bad.
To me, dup isn't bad since we won't see those change not on top.
Dup is possibly good when we breaks the repo during some merge/rebase

Comment 2

[Junior [inactive]]

I vote for being non-publish now.

Now we have around 50 patches unlanded, so hg graft isn't good enough.
This time I use hg phase -d -r A1 --force and hg rebase -s A1 -d C
In the final step, I need to hg push -r tip --force since all rebased node are phase divergent.

Not sure if hg evolve --phase-divergent is safe for this case or not.
I try to give it a taste and the working directory is going to mess.

Comment 3

[Connor Sheehan [:sheehan]]

I have set the repo to non-publishing. Any new pushes will be in the "draft" state, and history rewriting operations should be easier.

Unfortunately it appears that simply demoting a published changeset back to draft and pushing does not update the server state, in fact the demoted changesets will be promoted back to published. So it will take a little more work from me to get the existing changes into draft state on the server. I'm going to experiment with a user repo and report back.

Comment 4

[Junior [inactive]]

I realize my pushes yesterday were draft. Thanks.

Comment 5

[Connor Sheehan [:sheehan]]

Larch has been a non-publishing for some time now, so I'm going to close this out. :)

Comment 6

[Junior [inactive]]

Thanks :sheehan!