~bzr-pqm/bzr/bzr.dev : contents of doc/compared-aegis.txt at revision 1185.50.2

~bzr-pqm/bzr/bzr.dev : (revision 1185.50.2)

****************
Ideas from Aegis
****************

* Very mature -- in use for 14 years, many large projects, etc.

* "Essential process can be learned in a day" -- which is still kind
  of a long time; i'd like it to be well under an hour.

* Good process integration; show who is supposed to be working on what
  and how far through they are.

* Very poor Windows support.

* Distributed repositories. (??)

* Very focussed on security -- can reproduce any previous revision;
  availability/integrity/confidentiality; uses Unix permissions and
  seteuid() to prevent users changing the database.

* Does not itself track history -- assumes this will be done by some
  other tool such as RCS operating on the baseline.

* I think every individual project needs a single baseline. (??)

* The baseline is always working and always releasable -- to the
  extent that you have scripts which can enforce this.

* Integration step is somewhat similar to that used by distributed
  systems.  It seems that you could build some features of aegis as
  policy macros on top of Bazaar-NG.

* The baseline also contains object files built from current source,
  which can be used to pre-populate working directories.  Also people
  only need a copy of the source files they're changing.  I think the
  economics of this have changed a bit.  Also tends to assume all
  developers are on the same Unix host, which is no longer generally
  true.

* Only one review/integration can be in process at a time.

* One process difference is that developers produce all changes;
  reviewers/integrators can only accept or reject them.  This is
  different from the integrator-makes-right model of many distributed
  tools.  (Though the integrator still has the choice to reject, but
  they have the option of fixing it too.)

* Can automatically append Signed-off-by field.  Interesting idea.  I
  wonder if we should have a metadata facility to include licence
  data?

* Much of the functionality of Aegis is to prevent people doing things
  they could otherwise do.  That can be useful in enforcing a healthy
  process but bazaar-ng is not the place for it. 

* Can serialize an (in-progress) changeset to text, and then mail from
  one place to another.

* Branches are an extension of the 'change' concept; they can be
  merged into the parent in the same way that a change can be.

  Merging branches onto the mainline seems to hit a similar problem to
  that of centralized branches.  If someone else has committed, you
  need to make a new changeset reconciling all their changes, commit
  that to the child branch, then commit everything to the parent.

  This suggests a different way to do shared branches in Bazaar-NG:

    You can push to the parent if you incorporate either directly or
    by merger all changes on the parent.  That means that everything
    someone has committed to the parent is present in some way in your
    branch.  By extension, it is safe to transform the parent text
    into your branch without losing anything.  We can therefore
    remotely record that changeset to the parent.  This is more or
    less what Aegis does.

    The problem with this in the Bazaar-NG model is that then the new
    commit will be only in the parent, and not on the child.  So if
    you run ``bzr log`` on the child, you won't see what you just
    committed.  We can't apply it to both because the predecessor is
    different.  (darcs could do that, but it has a looser patch
    history than I want.)




Overall, the process model is good for a particular type of
organization.  It would be good to build this on top of Bazaar-NG.  To
support that we need:

 - patches are submitted, rather than being directly written in 

 - arbitrary levels of branching/review

 - users can submit changes to branches they are not directly allowed
   to write to 

 - branches can be cleanly removed when they're no longer necessary

 - strong audit trail


Interestingly, the BitKeeper model which is criticized__ by Greg
Hudson is similar to that of Aegis: a single integrator (or small
team?) who ultimately decide what gets into the main tree.

__ http://web.mit.edu/ghudson/thoughts/bitkeeper.whynot


The Aegis workflow can probably be `emulated in bzr <workflow.html>`_.

1185.1.29 by Robert Collins merge merge tweaks from aaron, which includes latest .dev	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>`_.