This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Joern Rennecke wrote: > It has a concept > > called an MR which is an ECMS object that keeps track of a group of > > changes that are logically related. (For example, all the changes for a new > > register allocator would be on one MR.) One file can be changed more > > than once on the same MR. The second great featue was given MRs A, > > B, C, and D have been created (in that order), ECMS would let users extract > > a copy of the code that included any combination of these changes (MRs). > > For example, someone could get all changes for MR C, without getting > > changes for MRs A, B, or D. This is very useful because you can run the > > regression tests on each MR independently, and not "approve" an MR until > > the tests pass. > > I don't see how this differs from CVS branches. Think of it as the difference between a tape drive (sequential access) and a disk drive (random access). As an example, consider code that Joe made a change, then Jill, then Jack. In CVS your choices are to get (1) none of the changes, (2) Joe's change, (3) Joe + Jill's changes, or (4) Joe + Jill + Jack's changes. In ECMS you can get the changes in any of these combinations:: 1. none 2. joe 3. jill 4. jack 5. joe+jill 6. joe+jack 7. jill+jack 8 joe+jill+jack The beauty is if Joe's changes turn out to have a bug, people can still get Jill and Jack's changes without getting Joe's bad changes. Brian Beuning
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |