Bugzilla – Full Text Bug Listing
| Summary: | [Papyrus] A lot of contribution stuck in Submitted, Merge Pending | ||
|---|---|---|---|
| Product: | Community | Reporter: | Benoit Maggi <benoit.maggi> |
| Component: | Gerrit | Assignee: | Eclipse Webmaster <webmaster> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | critical | ||
| Priority: | P3 | CC: | cletavernier, denis.roy, francois.le-fevre, give.a.damus, rschnekenburger |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
|
Description
Benoit Maggi
Could this be related to your Cherry-pick strategy? I always use either Rebase as necessary or Fast-forward only. When patches overlap, I would assume cherry-pick requires you to cherry pick and push a merge commit manually. Good point. Basically, what you're saying is that Gerrit is punting the merge step back to the committer team in these cases, right? I would vote for rebase-as-necessary. Exactly. If you don't want Gerrit rebasing automatically, Fast Forward Only will allow committers to rebase with a Rebase button on the Gerrit UI. Your call, we'll do as you wish. Did you check the logs ? If I understand your point, this is the use case you supposed : - 2 patches are conflicting (but not detected by gerrit because of the cherry pick strategy) - review&merge patch 1 in the gerrit ui - review&merge patch 2 in the gerrit ui - the patch 1 is cherry picked in master - the patch 2 can't be cherry-picked because of a conflict but is already reviewed so it stay stuck in merge pending. Did I understand your supposition correctly ? I'm afraid it's no that. I got one patch stuck in mere pending. I checkout&amend&re-push to gerrit => Gerrit didn't detect a conflict => review&merge => the patch is stuck again Nevertheless : If changing the merging strategy again can solve the problem, let's do it. We may have to send an email to the dev mailing list. I will also be in favor of a Fast-Forward strategy Rebase if necessary or cherry pick if necessary would be OK for me. Rebasing manually from Gerrit would trigger a new build, whereas letting Gerrit do it during submit does not. We don't really need this overhead :) [2015-07-08 03:33:06,074] ERROR com.google.gerrit.server.git.ChangeMergeQueue : Merge attempt for papyrus/org.eclipse.papyrus,refs/heads/master failed
com.google.gerrit.server.git.MergeException: Cannot merge 2e830425e45dc41a5c20459ded6454c0490c8f57
at com.google.gerrit.server.git.strategy.CherryPick._run(CherryPick.java:126)
at [snip]
Caused by: java.sql.BatchUpdateException: Duplicate entry '50262-2-1' for key 1
[snip]
Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLIntegrityConstraintViolationException: Duplicate entry '50262-2-1' for key 1
I tracked it down to this:
https://code.google.com/p/gerrit/issues/detail?id=2383
Seems there's a long-standing issue with the Cherry Pick strategy.
I've cleared out patch-set #2 in the database since it doesn't appear there is one. Let's see if Gerrit can sort it out now.
Ick ... seems to be serious issues with Cherry-pick: https://code.google.com/p/gerrit/issues/detail?id=2094 Right now, 50262 is stuck at: [2015-07-08 07:53:13,708] ERROR com.google.gerrit.server.git.ChangeMergeQueue : Merge attempt for papyrus/org.eclipse.papyrus,refs/heads/master failed com.google.gerrit.server.git.MergeException: Cannot update refs/heads/master at com.google.gerrit.server.git.MergeOp.updateBranch(MergeOp.java:640) Caused by: java.io.IOException: REJECTED let's go back to the fast forward strategy (In reply to Benoit Maggi from comment #8) > let's go back to the fast forward strategy +1 I've changed papyrus and papyrus-tools to FF only. I'll see what I can do about 50262, it seems dead. We'll also notify other projects that are using Cherry Pick. We can't risk breaking repositories this way. (In reply to Denis Roy from comment #10) > > We'll also notify other projects that are using Cherry Pick. We can't risk > breaking repositories this way. Thanks for looking out for, Denis, as usual! Thanks Also for https://git.eclipse.org/r/#/c/45932/ I got Not Found The page you requested was not found, or you do not have permission to view this page. Should we do something specific for commits stuck in merge pending ? Is it possible for one of you to amend a commit for 50262, Change-Id: I7f62835d32506ca85d3ae4ef2e08effe79b65403 ? I want to see if that will trigger the rebase or merge action. Big thanks pending contribution are merging right now. For https://git.eclipse.org/r/#/c/45932/ It has been merged see 6379bc1cc60c6d7ece710255f2509abfd44bc60a but the gerrit web ui is still not working. For I7f62835d32506ca85d3ae4ef2e08effe79b65403 I can just rebase it ? Or there is a specific need for ammend ? (In reply to Benoit Maggi from comment #14) > For I7f62835d32506ca85d3ae4ef2e08effe79b65403 > I can just rebase it ? Or there is a specific need for ammend ? I think you should rebase locally the push an amended commit if you can. Otherwise Gerrit may think it's a new change. Once we have all this sorted out, you'll be able to rebase from the Gerrit UI. > For https://git.eclipse.org/r/#/c/45932/ > It has been merged see 6379bc1cc60c6d7ece710255f2509abfd44bc60a > > but the gerrit web ui is still not working. I'm not sure what to do with this one. If that change was merged successfully, could try removing the extraneous patchsets so that the change reflects reality, but I don't want to break it. > I think you should rebase locally the push an amended commit
^^^ then
For refs/changes/24/51224/16 I tried rebase/cherry-pick but I always end up with remote reject "change 51224 missing revisions" https://git.eclipse.org/r/#/c/51224/ I've removed the extraneous patch-sets and ancestors, and it's back to life. Merge locally, amend, submit :) Thanks a lot for your help. I have still some gerrit ui breaks: -https://git.eclipse.org/r/#/c/50503/ -https://git.eclipse.org/r/#/c/51054/ I have tried to download them via eclipse but I got strange elements. Could you do something to restore those gerrit web uis? Thanks again. Francois, from France I've brought those back to life. Just to document what I've done: select current_patch_set_id from changes where change_id = 51054; +----------------------+ | current_patch_set_id | +----------------------+ | 19 | +----------------------+ select * from patch_sets where change_id = 51054; +------------------------------------------+---------------------+---------------------+-----------+--------------+-------+ | revision | uploader_account_id | created_on | change_id | patch_set_id | draft | +------------------------------------------+---------------------+---------------------+-----------+--------------+-------+ | 22eb4ac24d472bd6585498ccaa50177b69942c67 | 10533 | 2015-06-29 11:36:13 | 51054 | 1 | N | | b269bb3ddb4b37f517568851668752747af80b62 | 10533 | 2015-07-01 04:40:02 | 51054 | 2 | N | | 2cd58f91a5ba72469588fc853db868eccfe61e62 | 10533 | 2015-07-02 06:52:08 | 51054 | 3 | N | | ffeae3f2471fa5b1c37cf4594592c7eb4d67eedd | 5293 | 2015-07-06 11:47:59 | 51054 | 4 | N | | 033e3dab98d348baf59b9de7bd370af57d588e1b | 5293 | 2015-07-07 05:31:51 | 51054 | 5 | N | | fbb7fc0999e4ede3ade1456385df6b8aa570205a | 5293 | 2015-07-08 07:43:11 | 51054 | 6 | N | | fbb7fc0999e4ede3ade1456385df6b8aa570205a | 5293 | 2015-07-08 07:48:12 | 51054 | 7 | N | | fbb7fc0999e4ede3ade1456385df6b8aa570205a | 5293 | 2015-07-08 07:53:11 | 51054 | 8 | N | | fbb7fc0999e4ede3ade1456385df6b8aa570205a | 5293 | 2015-07-08 07:58:10 | 51054 | 9 | N | | fbb7fc0999e4ede3ade1456385df6b8aa570205a | 5293 | 2015-07-08 08:03:10 | 51054 | 10 | N | | fbb7fc0999e4ede3ade1456385df6b8aa570205a | 5293 | 2015-07-08 08:08:10 | 51054 | 11 | N | | fbb7fc0999e4ede3ade1456385df6b8aa570205a | 5293 | 2015-07-08 08:13:10 | 51054 | 12 | N | | fbb7fc0999e4ede3ade1456385df6b8aa570205a | 5293 | 2015-07-08 08:18:10 | 51054 | 13 | N | | fbb7fc0999e4ede3ade1456385df6b8aa570205a | 5293 | 2015-07-08 08:23:14 | 51054 | 14 | N | | fbb7fc0999e4ede3ade1456385df6b8aa570205a | 5293 | 2015-07-08 08:28:10 | 51054 | 15 | N | | fbb7fc0999e4ede3ade1456385df6b8aa570205a | 5293 | 2015-07-08 08:33:10 | 51054 | 16 | N | | fbb7fc0999e4ede3ade1456385df6b8aa570205a | 5293 | 2015-07-08 08:38:10 | 51054 | 17 | N | | fbb7fc0999e4ede3ade1456385df6b8aa570205a | 5293 | 2015-07-08 08:43:10 | 51054 | 18 | N | | fbb7fc0999e4ede3ade1456385df6b8aa570205a | 5293 | 2015-07-08 08:48:10 | 51054 | 19 | N | +------------------------------------------+---------------------+---------------------+-----------+--------------+-------+ In the above case, patch_set > 6 is bogus from the repetitive revs. delete from patch_set_ancestors where change_id = 51054 and patch_set_id > 6; Query OK, 13 rows affected (0.03 sec) delete from patch_sets where change_id = 51054 and patch_set_id > 6; Query OK, 13 rows affected (0.00 sec) update changes set current_patch_set_id = 6 where change_id = 51054; Query OK, 1 row affected (0.00 sec) Denis: merci/gracias/thanks ! I'll close this as fixed... Just add a comment if you see anything else out of order. (In reply to Denis Roy from comment #22) > I'll close this as fixed... Just add a comment if you see anything else out > of order. Hi Denis, It seems that the Fast forward strategy fixes the issue, but it does not scale well our number of contributors and build time. That means that it would be better for us to go for a rebase if necessary solution, to ease external contributions and reduce committers/server loads. Could You please do the change? Merci! Sorry for changing strategy again! Regards, Remi Hi Remi, I've made the change to all the papyrus repos, not a problem. Closing fixed -- please reopen if you need anything else. |