This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Beyond GCC 3.0
- To: Joern Rennecke <amylaar at redhat dot com>, gcc at gcc dot gnu dot org
- Subject: Re: Beyond GCC 3.0
- From: Brian Beuning <bbeuning at mindspring dot com>
- Date: Thu, 28 Jun 2001 22:38:08 -0400
- References: <200106281339.f5SDdm815467@phal.cambridge.redhat.com>
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