| 1 |
On 04/24/2013 07:21 AM, Peter Stuge wrote: |
| 2 |
> Jeroen Roovers wrote: |
| 3 |
>> Er, you can't be seriously suggesting we will drop repoman checks |
| 4 |
>> with the migration to git? I don't see how that would benefit anyone. |
| 5 |
> |
| 6 |
> I would argue that repoman and/or corresponding checks should be run |
| 7 |
> by a CI system hooked up to the Gerrit instance that developers push to. |
| 8 |
> |
| 9 |
> Anything else is IMO waste of developers' time and minds. |
| 10 |
|
| 11 |
I was thinking something similar, actually, except you'd need something |
| 12 |
like this: |
| 13 |
|
| 14 |
1. dev pushes to Gerrit |
| 15 |
2. Gerrit does processing |
| 16 |
3. Gerrit pushes to tree, if tests pass. |
| 17 |
|
| 18 |
It would necessitate needing a separate mechanism to be able to undo |
| 19 |
changes to tree that broke things Gerrit missed, or it would necessitate |
| 20 |
"undo" steps being pushed through Gerrit. Both have their disadvantages. |
| 21 |
|
| 22 |
It might also result in only being able to push one changeset at a time, |
| 23 |
due to this scenario: |
| 24 |
|
| 25 |
1. Dev A pulls from tree |
| 26 |
2. Dev A merges those changes with his local copy of tree |
| 27 |
3. Dev A pushes to Gerrit |
| 28 |
4. Gerrit begins tests on changeset A |
| 29 |
5. Dev B pulls from tree (or perhaps he pulled earlier) |
| 30 |
6. Gerrit is still testing changeset A |
| 31 |
7. Dev B merges those changes with his local copy of tree |
| 32 |
8. Gerrit finishes testing, pushes to tree |
| 33 |
9. Dev B pushes to Gerrit |
| 34 |
10. Gerrit runs tests on changeset B |
| 35 |
11. Gerrit finishes tests, pushes to tree |
| 36 |
13. Gerrit's push to tree fails, since tree with changeset A isn't in |
| 37 |
changeset B's ancestry. |
| 38 |
|
| 39 |
Though you might be able to get around that by using git's email |
| 40 |
features to email diffs, allowing Gerrit to pipeline them (unless one |
| 41 |
diff set fails to apply after another has been applied, of course). |
Archives