From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19484 invoked by alias); 15 Dec 2002 05:17:19 -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 19020 invoked from network); 15 Dec 2002 05:15:56 -0000 Received: from unknown (HELO neon-gw.transmeta.com) (63.209.4.196) by 209.249.29.67 with SMTP; 15 Dec 2002 05:15:56 -0000 Received: (from root@localhost) by neon-gw.transmeta.com (8.9.3/8.9.3) id VAA12906; Sat, 14 Dec 2002 21:14:51 -0800 Received: from mailhost.transmeta.com(10.1.1.15) by neon-gw.transmeta.com via smap (V2.1) id xma012902; Sat, 14 Dec 02 21:14:38 -0800 Received: from home.transmeta.com ([10.8.17.140]) by deepthought.transmeta.com (8.11.6/8.11.6) with ESMTP id gBF5EiR10875; Sat, 14 Dec 2002 21:14:44 -0800 (PST) Date: Sat, 14 Dec 2002 22:12:00 -0000 From: Linus Torvalds To: Tom Lord cc: gcc@gcc.gnu.org Subject: Re: source mgt....[_HAS_ gcc relevance] In-Reply-To: <200212150448.UAA01297@emf.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2002-12/txt/msg00820.txt.bz2 On Sat, 14 Dec 2002, Tom Lord wrote: > > The advantage of the SCM-assisted merges is really that when > you trust the other side, it becomes a non-issue. > > It helps even when you don't implicitly trust the other side. Sorry, you're right, and that's really what I mean. To give write access to the tree you _really_ have to trust the other guy. You have to trust him not only today, but you have to trust his judgement in the long term. Which is why open source projects don't tend to give write access to CVS trees very lightly, and as a result you tend to have a fairly small "clique" of trusted developers. In contrast, for a one-time merge you only have to trust "that merge". Which is a different thing altogether, and doesn't require any kind of "implicit trust". > A remote, less-than-implicitly-trusted developer submits a patch. You > kick it back with comments. Meanwhile, your mainline has gone on. > > Before resubmitting, that developer has to update his patch to reflect > the new head-of-mainline. > > If that remote developer has his own repository, but a true, > first-class branch of your mainline, then he can use SCM-assisted > merges to keep his patch up-to-date. Absolutely. And he can still use SCM-assisted merges with his cohorts to fix whatever issues you brought up: that's also an important part of a distributed SCM. Many people want to check stuff into the CVS tree _not_ because they really want everybody to see the thing, but because they use the CVS tree as a way to communicate with a few other people working on the same thing. That's where the "single main repository" _really_ falls down. CVS tends to use branches for this, but I do not know a single CVS user who isn't a bit nervous about creating a new branch. That's true even when you don't have the "write access" issue. In contrast, with a good distributed system, if you want to just communicate with some other people working on the same thing, you can merge only the _affected_ trees, not the "main" tree. Merge into the main tree only when you're done and the people involved are happy. Linus