1 |
On Wed, Apr 24, 2013 at 7:47 AM, Michael Mol <mikemol@×××××.com> wrote: |
2 |
> |
3 |
> 13. Gerrit's push to tree fails, since tree with changeset A isn't in |
4 |
> changeset B's ancestry. |
5 |
> |
6 |
|
7 |
Honestly, this is a problem with any use of repoman with git unless |
8 |
you let the server auto-merge trivial changes. Cvs tracks commits at |
9 |
the file level, and git does it at the repository level. The chances |
10 |
of somebody modifying the same files in the time it takes you to |
11 |
stage, test, and commit a change in cvs are fairly low. The chances |
12 |
of somebody making any commit to the repository in the time it takes |
13 |
you to rebase, do a repoman check, and push are much higher. |
14 |
|
15 |
We might have to live with repoman being a manual process - then you'd |
16 |
just pull/rebase-or-merge/push to get it to the tree and use your |
17 |
brain to determine if it causes any problems (which does require |
18 |
responsibility). |
19 |
|
20 |
However, your specific example could be modified a bit to make it more robust: |
21 |
|
22 |
1. Dev A pulls from tree |
23 |
2. Dev A merges those changes with his local copy of tree |
24 |
3. Dev A pushes to Gerrit |
25 |
4. Gerrit begins tests on changeset A |
26 |
5. Dev B pulls from tree (or perhaps he pulled earlier) |
27 |
6. Gerrit is still testing changeset A |
28 |
7. Dev B merges those changes with his local copy of tree |
29 |
8. Gerrit finishes testing, pushes to tree |
30 |
9. Dev B's push to Gerrit fails, since Gerrit's head isn't in B's ancestry. |
31 |
10. Dev B pulls, rebases, and re-pushes - possibly pulling directly |
32 |
from Gerrit to reduce latency. |
33 |
|
34 |
It still fails when you get high volumes, because the fundamental |
35 |
issue is that it can only handle as many commits as Gerrit can test in |
36 |
a given period of time, plus various latencies. |
37 |
|
38 |
Rich |