| 1 |
Developer Interaction model with Git |
| 2 |
------------------------------------ |
| 3 |
Aka, why merge lieutenants or co-ordinators might be useful |
| 4 |
|
| 5 |
This is amongst the potential problems I see might pop up. |
| 6 |
|
| 7 |
We have two developers, let's call them Alice & Bob. |
| 8 |
|
| 9 |
Alice has a nice fast internet connection, 10Mbit upstream. |
| 10 |
Bob has a really sucky internet connection, 128Kbit upstream. |
| 11 |
|
| 12 |
Alice is doing this set of commands, as she has a fast connection: |
| 13 |
- (work on an ebuild) |
| 14 |
- repoman commit |
| 15 |
- git pull (implicit merge) |
| 16 |
- git push |
| 17 |
|
| 18 |
Bob is doing this, as he has a slow intermittent connection |
| 19 |
- (work on an ebuild) |
| 20 |
- repoman commit |
| 21 |
- loop the above many times |
| 22 |
- git pull (implicit merge) |
| 23 |
- fix conflicts as needed |
| 24 |
- git push |
| 25 |
|
| 26 |
If there are enough "Alice" developers, is it a possibility that Bob |
| 27 |
will never have a chance to get his commit in? |
| 28 |
|
| 29 |
All this requires, is that in the time it takes Bob to do 'git pull', |
| 30 |
Alice manages to do 'git push' again. |
| 31 |
|
| 32 |
Alice can thus deprive Bob of a fair chance to get his commit in. |
| 33 |
Bob becomes an unhappy developer and gives up. |
| 34 |
|
| 35 |
Is this a realistic problem you ask? As recently as one or two years |
| 36 |
ago, we still have developers on 56K or worse modems at home. |
| 37 |
|
| 38 |
A variant of the above problem also happens as the number of developers |
| 39 |
grows, you're almost always out of date trying to push to a single |
| 40 |
branch if it's moving fast enough. |
| 41 |
|
| 42 |
If this does happen, what can we do about it? |
| 43 |
|
| 44 |
We have two options: |
| 45 |
Both of them imply that each developer will have a private branch, |
| 46 |
dev/$FOO, that only they are able to commit into. |
| 47 |
|
| 48 |
A hierarchy of merge lieutenants: |
| 49 |
- This is basically the Linux kernel model. The ability to merge into |
| 50 |
master resides with a single person, and he pulls from other known |
| 51 |
specified developers, who serve to collect and fix conflicts as needed |
| 52 |
from the general developer population. |
| 53 |
A merge co-ordinators that switches with time. |
| 54 |
- This resembles the model used by Mozilla. |
| 55 |
- Switches on a time basis; is generally some developer with a fast |
| 56 |
internet connection. |
| 57 |
- Responsible for taking pull requests, merging, fixing conflicts or |
| 58 |
punting back, and pushing to the master branch. |
| 59 |
|
| 60 |
-- |
| 61 |
Robin Hugh Johnson |
| 62 |
Gentoo Linux: Developer, Trustee & Infrastructure Lead |
| 63 |
E-Mail : robbat2@g.o |
| 64 |
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 |
Archives