From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-46802-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 11353 invoked by alias); 22 Feb 2002 02:02:48 -0000
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
Received: (qmail 11265 invoked from network); 22 Feb 2002 02:02:43 -0000
Received: from unknown (HELO boden.synopsys.com) (204.176.20.19)
  by sources.redhat.com with SMTP; 22 Feb 2002 02:02:43 -0000
Received: from mother.synopsys.com (mother.synopsys.com [146.225.100.171])
	by boden.synopsys.com (Postfix) with ESMTP
	id 13788DD68; Thu, 21 Feb 2002 18:02:43 -0800 (PST)
Received: from atrus.synopsys.com (localhost [127.0.0.1])
	by mother.synopsys.com (8.9.1/8.9.1) with ESMTP id SAA23138;
	Thu, 21 Feb 2002 18:02:37 -0800 (PST)
From: Joe Buck <jbuck@synopsys.COM>
Received: (from jbuck@localhost)
	by atrus.synopsys.com (8.9.3+Sun/8.9.1) id SAA16504;
	Thu, 21 Feb 2002 18:02:42 -0800 (PST)
Message-Id: <200202220202.SAA16504@atrus.synopsys.com>
Subject: Re: GCC 3.0.4 Released
To: jsm28@cam.ac.uk (Joseph S. Myers)
Date: Thu, 21 Feb 2002 18:07:00 -0000
Cc: jbuck@synopsys.COM (Joe Buck),
	mark@codesourcery.com (Mark Mitchell),
	gcc@gcc.gnu.org (gcc@gcc.gnu.org)
In-Reply-To: <Pine.LNX.4.33.0202220145120.15081-100000@kern.srcf.societies.cam.ac.uk> from "Joseph S. Myers" at Feb 22, 2002 01:50:26 AM
X-Mailer: ELM [version 2.5 PL2]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-SW-Source: 2002-02/txt/msg01242.txt.bz2

> On Thu, 21 Feb 2002, Joe Buck wrote:
> 
> > You're thinking of developers as opposed to end users, who will only be
> > using FSF releases.  For them, diffs from 3.0.4 to 3.1 will be useful if
> > the size is substantially smaller than just downloading 3.1.
> 
> They're also quite likely to run into limitations of gcc_update - even if
> they do run it after patching to adjust timestamps, by design it touches
> files in CVS only, so the timestamps of generated files that aren't in CVS
> may well be wrong after patching.

If the patch is ordered in such a way that diffs to derived files appear after
diffs to the base files, then gcc_update is not needed.