From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1871 invoked by alias); 8 Dec 2002 22:18:16 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 1864 invoked from network); 8 Dec 2002 22:18:15 -0000 Received: from unknown (HELO fencepost.gnu.org) (199.232.76.164) by sources.redhat.com with SMTP; 8 Dec 2002 22:18:15 -0000 Received: from monty-python.gnu.org ([199.232.76.173]) by fencepost.gnu.org with esmtp (Exim 4.10) id 18L9kc-0001WI-00 for gcc@gnu.org; Sun, 08 Dec 2002 17:18:14 -0500 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18L9kG-0006NU-00 for gcc@gnu.org; Sun, 08 Dec 2002 17:17:53 -0500 Received: from anchor-post-33.mail.demon.net ([194.217.242.91]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18L9kF-0006Lr-00 for gcc@gnu.org; Sun, 08 Dec 2002 17:17:51 -0500 Received: from cenderis.demon.co.uk ([62.49.17.254] helo=localhost) by anchor-post-33.mail.demon.net with esmtp (Exim 3.35 #1) id 18L9kE-000BqW-0X for gcc@gnu.org; Sun, 08 Dec 2002 22:17:50 +0000 Received: by localhost (Postfix, from userid 1000) id 1239147D9D; Sun, 8 Dec 2002 22:17:50 +0000 (GMT) From: Bruce Stephens To: gcc@gnu.org Subject: Re: on reputation and lines and putting things places (Re: gcc branches?) References: <3DEBFF1F.8070603@bothner.com> <87y97752yp.fsf@egil.codesourcery.com> <3DEC018B.4090905@bothner.com> <87vg2b51my.fsf@egil.codesourcery.com> <200212030203.SAA27437@emf.net> <3DF116A7.3040308@bothner.com> <200212070708.XAA02044@emf.net> <20021207174847.A21533@disaster.jaj.com> <200212072340.PAA04425@emf.net> <3DF3BCB7.6060102@apple.com> Date: Sun, 08 Dec 2002 14:45:00 -0000 In-Reply-To: <3DF3BCB7.6060102@apple.com> (Stan Shebs's message of "Sun, 08 Dec 2002 13:42:15 -0800") Message-ID: <87ptscm9yq.fsf@cenderis.demon.co.uk> User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-9.0 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_MULTIHOP_DSBL,RCVD_IN_UNCONFIRMED_DSBL,REFERENCES, SPAM_PHRASE_03_05,USER_AGENT version=2.41 X-Spam-Level: X-SW-Source: 2002-12/txt/msg00431.txt.bz2 Stan Shebs writes: [...] > Now, almost all of *my* merge difficulties have been because Apple > changes to GCC are logically contradictory to FSF code. Does arch > include an intelligent merging component that is smart about C and > can figure out which pieces of FSF code need to be overridden by > Apple code, even if the FSF code changed? No, but (like other modern CM systems) it remembers what's been merged. So with CVS, you develop on a branch (presumably updating with whats on the head), and when you want to update the head, CVS does textual guessing to decide which apparent conflicts are real ones (and this usually works pretty well, to be fair). Arch remembers the updates you've done on your branch, so when you want to update the head, you'll get fewer spurious conflicts. So with arch, it makes sense to keep branches up to date with respect to each other---it makes future merges easier. With CVS, it's sometimes the opposite. (Arch knows about file renames and things, too, which would matter for some projects, but possibly not gcc.) > If not, then for *me* it doesn't have any advantage over CVS, and > there's no point in trying to sell it to me. Maybe not. It's hard to say without looking in more detail and trying experiments. [...]