forked from brazilofmux/tinymux
-
Notifications
You must be signed in to change notification settings - Fork 0
/
branching
115 lines (88 loc) · 4.7 KB
/
branching
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
Grand Branching Scheme
1. Introduction.
In the past, a single trunk branch with tagged builds was sufficient to
accommodate the flow of changes from the active developers. Every developer
committed their changes directly into the main trunk. CVS branching was
error-prone and the clean-up risk was too high, so the project just didn't use
that feature of CVS.
With one branch, a single person tends to be the gate-keeper. Patches flow to
this person, and changes made directly to the repository are at risk of being
reverted.
In thinking about what branching scheme best fits our needs, we are guided by
the following requirements:
- A significant part of the quality assurance feedback originates externally,
so it is not practical to assume a highly-organized internal QA function.
- Internal QA consists primarily of code inspection by other developers.
Changes coming from other developers should be combined/compacted to make
inspection easier.
- Since TinyMUX is developed for Win32 and various flavors of Unix, it isn't
possible to know whether code that compiles and runs on one platform will
necessarily compile and run on another. In fact, not all developers have
access to all platforms and are unable to completely verify their changes.
- Most volunteer developers are intermittently active.
2. Branch Organization.
To meet these requirements, we have chosen the following branching scheme:
----2.12.0---2.12.1
/
-----------------------------------------------------
trunk \
\ dev
------------------------
\
\ dev_brazil
------------
\
\ dev_firan
-----------
\
\ dev_ian
-----------
In the Grand Scheme, the trunk is used only for alpha releases, and the only
changes allowed are merges from other branches. For beta and maintenance
work, releases are made from release-side branches described later.
2.1. Developer-Side Branches.
It's useful to first classify branches besides the trunk into development-side
branches and release-side branches. The development-side branches can be
organized into a promotion tree like so:
trunk
|
|
dev
|
|-------------------------
| | |
dev_brazil dev_firan dev_ian
An individual developer (e.g., Brazil) would make changes in branch dev_brazil,
test their changes on Win32 and some flavors of Unix. There is still a strong
desire to see simple changes committed individually -- changes which address
the code in only one dimension to make it easier for others to code review the
changes. There is also a strong desire to avoid breaking the build in these
private branches, however, the only person affected by a broken build is the
developer who broke it.
Periodically, changes made on dev_brazil, dev_firan, and dev_ian branches
are merged into the dev branch, and periodically, changes from dev are merged
into the trunk. Likewise, changes brought into dev are periodically merged
down into dev_brazil, dev_firan, and dev_ian.
2.2. Release-Side Branches.
The other class of branches are the release-side branches. Periodically, a
release branch is created from the trunk. Packaging considerations may
require certain minor changes. Maintenance of a release can be supported with
bug fixes. Each release branch may require a slightly different fix, but
typically the fix from the most-recently released branch is merged back into
the trunk, and propagated back down the dev tree.
3. Concluding Remarks.
Of course, with all this merging up and down the tree, there is always the
potential for merge conflicts, and these would need to be resolved manually.
Any change to the code should be made in exactly one branch and then allowed
to propagate to everywhere else along with the other changes.
Rather than associate each leaf branch directly with a developer, it would
have been possible to create an arbitrary number. Each developer could then
pick for themselves which leaf they would work in. This approach would have
scaled better. As it is, newer developers are working in branches named after
older, now-idle developers.
We are now using a combination of SVN and GIT with much better support for
branching. Control of work is formalized in the Issue database. It is
preferred that no change (no matter how mundane) is made unless there is an
Issue that covers and approves it. Furthermore, instead of a single
gate-keeper, each leaf branch can have its own gate-keeper, impose their own
rules, fulfill their own internal QA function in their own way.