|
6
by mbp at sourcefrog
import all docs from arch |
1 |
**************** |
2 |
Ideas from Aegis |
|
3 |
**************** |
|
4 |
||
5 |
* Very mature -- in use for 14 years, many large projects, etc. |
|
6 |
||
7 |
* "Essential process can be learned in a day" -- which is still kind |
|
8 |
of a long time; i'd like it to be well under an hour. |
|
9 |
||
10 |
* Good process integration; show who is supposed to be working on what |
|
11 |
and how far through they are. |
|
12 |
||
13 |
* Very poor Windows support. |
|
14 |
||
15 |
* Distributed repositories. (??) |
|
16 |
||
17 |
* Very focussed on security -- can reproduce any previous revision; |
|
18 |
availability/integrity/confidentiality; uses Unix permissions and |
|
19 |
seteuid() to prevent users changing the database. |
|
20 |
||
21 |
* Does not itself track history -- assumes this will be done by some |
|
22 |
other tool such as RCS operating on the baseline. |
|
23 |
||
24 |
* I think every individual project needs a single baseline. (??) |
|
25 |
||
26 |
* The baseline is always working and always releasable -- to the |
|
27 |
extent that you have scripts which can enforce this. |
|
28 |
||
29 |
* Integration step is somewhat similar to that used by distributed |
|
30 |
systems. It seems that you could build some features of aegis as |
|
31 |
policy macros on top of Bazaar-NG. |
|
32 |
||
33 |
* The baseline also contains object files built from current source, |
|
34 |
which can be used to pre-populate working directories. Also people |
|
35 |
only need a copy of the source files they're changing. I think the |
|
36 |
economics of this have changed a bit. Also tends to assume all |
|
37 |
developers are on the same Unix host, which is no longer generally |
|
38 |
true. |
|
39 |
||
40 |
* Only one review/integration can be in process at a time. |
|
41 |
||
42 |
* One process difference is that developers produce all changes; |
|
43 |
reviewers/integrators can only accept or reject them. This is |
|
44 |
different from the integrator-makes-right model of many distributed |
|
45 |
tools. (Though the integrator still has the choice to reject, but |
|
46 |
they have the option of fixing it too.) |
|
47 |
||
48 |
* Can automatically append Signed-off-by field. Interesting idea. I |
|
49 |
wonder if we should have a metadata facility to include licence |
|
50 |
data? |
|
51 |
||
52 |
* Much of the functionality of Aegis is to prevent people doing things |
|
53 |
they could otherwise do. That can be useful in enforcing a healthy |
|
54 |
process but bazaar-ng is not the place for it. |
|
55 |
||
56 |
* Can serialize an (in-progress) changeset to text, and then mail from |
|
57 |
one place to another. |
|
58 |
||
59 |
* Branches are an extension of the 'change' concept; they can be |
|
60 |
merged into the parent in the same way that a change can be. |
|
61 |
||
62 |
Merging branches onto the mainline seems to hit a similar problem to |
|
63 |
that of centralized branches. If someone else has committed, you |
|
64 |
need to make a new changeset reconciling all their changes, commit |
|
65 |
that to the child branch, then commit everything to the parent. |
|
66 |
||
67 |
This suggests a different way to do shared branches in Bazaar-NG: |
|
68 |
||
69 |
You can push to the parent if you incorporate either directly or |
|
70 |
by merger all changes on the parent. That means that everything |
|
71 |
someone has committed to the parent is present in some way in your |
|
72 |
branch. By extension, it is safe to transform the parent text |
|
73 |
into your branch without losing anything. We can therefore |
|
74 |
remotely record that changeset to the parent. This is more or |
|
75 |
less what Aegis does. |
|
76 |
||
77 |
The problem with this in the Bazaar-NG model is that then the new |
|
78 |
commit will be only in the parent, and not on the child. So if |
|
79 |
you run ``bzr log`` on the child, you won't see what you just |
|
80 |
committed. We can't apply it to both because the predecessor is |
|
81 |
different. (darcs could do that, but it has a looser patch |
|
82 |
history than I want.) |
|
83 |
||
84 |
||
85 |
||
86 |
||
87 |
Overall, the process model is good for a particular type of |
|
88 |
organization. It would be good to build this on top of Bazaar-NG. To |
|
89 |
support that we need: |
|
90 |
||
91 |
- patches are submitted, rather than being directly written in |
|
92 |
||
93 |
- arbitrary levels of branching/review |
|
94 |
||
95 |
- users can submit changes to branches they are not directly allowed |
|
96 |
to write to |
|
97 |
||
98 |
- branches can be cleanly removed when they're no longer necessary |
|
99 |
||
100 |
- strong audit trail |
|
101 |
||
102 |
||
103 |
Interestingly, the BitKeeper model which is criticized__ by Greg |
|
104 |
Hudson is similar to that of Aegis: a single integrator (or small |
|
105 |
team?) who ultimately decide what gets into the main tree. |
|
106 |
||
107 |
__ http://web.mit.edu/ghudson/thoughts/bitkeeper.whynot |
|
108 |
||
109 |
||
110 |
The Aegis workflow can probably be `emulated in bzr <workflow.html>`_. |