From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25574 invoked by alias); 15 Dec 2002 05:34:48 -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 25566 invoked from network); 15 Dec 2002 05:34:48 -0000 Received: from unknown (HELO emf.net) (205.149.0.20) by sources.redhat.com with SMTP; 15 Dec 2002 05:34:48 -0000 Received: (from lord@localhost) by emf.net (K/K) id UAA01297; Sat, 14 Dec 2002 20:48:28 -0800 (PST) Date: Sat, 14 Dec 2002 23:12:00 -0000 From: Tom Lord Message-Id: <200212150448.UAA01297@emf.net> To: gcc@gcc.gnu.org CC: torvalds@transmeta.com In-reply-to: (message from Linus Torvalds on Sat, 14 Dec 2002 20:13:35 -0800 (PST)) Subject: Re: source mgt....[_HAS_ gcc relevance] References: X-SW-Source: 2002-12/txt/msg00821.txt.bz2 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. 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. A similar case occurs if you accept his patch, but then there's still more to be done with it -- further development. In that case, there's effectively back-and-forth merging between your mainline and his remote branch. "star topology merging" handles exactly that case. In relation to these features, it's interesting to read the recent narrowly-on-topic traffic on the gcc list (Mark and Zack's coordination with everyone else, comments about forming intermediate merges, and calls for help with testing branches). I think that some of the issues around synchronizing work would be somewhat relaxed by applying these features; intermediate merges would be well facilitated and _partially_ automated (regardless of access writes of the authors); testing branches could be made more effectively automated (again, orthogonally to access rights). -t