This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: basic-improvements merge status
- From: Mark Mitchell <mark at codesourcery dot com>
- To: Zack Weinberg <zack at codesourcery dot com>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Mon, 16 Dec 2002 00:42:02 -0800
- Subject: Re: basic-improvements merge status
--On Monday, December 16, 2002 12:11:44 AM -0800 Zack Weinberg
<zack@codesourcery.com> wrote:
Mark Mitchell <mark@codesourcery.com> writes:
It is not clear to me that any purpose is served by holding off the
merge to trunk until all these issues get resolved. We could instead
do the merge now and fix the problems on the mainline; this would let
people move forward with other work. It would probably be a good idea
in that case to hold off on further branch merges and other massively
destabilizing patches until these issues do get resolved.
I agree. These are really problems that should have been detected
and fixed on BIB, but they slipped through. Nobody's fault, just
how it is.
So, do the merge.
Thanks for the vote of confidence ...
... but I just discovered that I don't know how. "cvs update -j
gcc-3_4-basic-improvements-branch" tries to merge all of the merges
from the trunk to the branch BACK into the trunk, causing a ton of
spurious conflicts. What's the right way to do this? (I'm seriously
considering "diff -ruN 3.3/ 3.4b/ | (cd top-of-trunk/ && patch -p1 -E"!)
I think that *is* the right way, roughly.
Let's suppose you just merged the mainline to BIB, so that there's nothing
on mainline that's not on BIB.
Then, I would do something like:
cvs diff -r BIB -r HEAD | patch -p0
to suck the changes to BIB back into the HEAD. And then run around
removing files (if any) that were removed on BIB, but not on HEAD,
which is equivalent to what you said.
After all, what you're trying to do is just rename BIB to be mainline,
basically.
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com