From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11398 invoked by alias); 9 Dec 2002 00:09:03 -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 11391 invoked from network); 9 Dec 2002 00:09:02 -0000 Received: from unknown (HELO fencepost.gnu.org) (199.232.76.164) by sources.redhat.com with SMTP; 9 Dec 2002 00:09:02 -0000 Received: from monty-python.gnu.org ([199.232.76.173]) by fencepost.gnu.org with esmtp (Exim 4.10) id 18LBTp-00033s-01 for gcc@gnu.org; Sun, 08 Dec 2002 19:09:01 -0500 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18LBSh-0004pa-00 for gcc@gnu.org; Sun, 08 Dec 2002 19:07:52 -0500 Received: from gold.csi.cam.ac.uk ([131.111.8.12]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18LBSg-0004pU-00 for gcc@gnu.org; Sun, 08 Dec 2002 19:07:51 -0500 Received: from student.cusu.cam.ac.uk ([131.111.179.82] helo=kern.srcf.societies.cam.ac.uk ident=mail) by gold.csi.cam.ac.uk with esmtp (Exim 4.10) id 18LBSf-0003gn-00; Mon, 09 Dec 2002 00:07:49 +0000 Received: from jsm28 (helo=localhost) by kern.srcf.societies.cam.ac.uk with local-esmtp (Exim 3.35 #1 (Debian)) id 18LBSe-0007X0-00; Mon, 09 Dec 2002 00:07:48 +0000 Date: Sun, 08 Dec 2002 16:24:00 -0000 From: "Joseph S. Myers" X-X-Sender: To: Bruce Stephens cc: Subject: Re: source mgt. requirements solicitation In-Reply-To: <87lm30m85r.fsf@cenderis.demon.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-8.1 required=5.0 tests=EMAIL_ATTRIBUTION,FROM_ENDS_IN_NUMS,IN_REP_TO, MAILTO_TO_SPAM_ADDR,QUOTED_EMAIL_TEXT, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.41 X-Spam-Level: X-SW-Source: 2002-12/txt/msg00437.txt.bz2 On Sun, 8 Dec 2002, Bruce Stephens wrote: > Not on the central repository, no. But it might be that people > (people without write access to the main repository) could usefully > keep branches on their own repository (perhaps merging the patches in > at some stage). With CVS, that's not possible, but with a distributed > CM system it would be. Distributed CM could be a mixed blessing. Sometimes when people merge development from a branch to mainline the mainline ChangeLog such says "See ChangeLog.foobar on foobar-branch for details." (though I don't think this is a proper form of ChangeLog for such changes, the Changelog should describe the changes made to mainline following the usual standards). If the branch sat on someone's machine elsewhere, there's then a lot of potential for losing this information later if the machine goes away, fails, etc. - whereas the main repository is at least rsyncable and rsynced by various people. (Such problems could be avoided if there were a mechanism by which such branches of interest - probably including any discussed on the list, could be "adopted" into the main repository, so that their history (maintained on some other machine) is regularly made available from the main rsyncable repository and isn't lost if the originating machine goes away. This applies even to branches that don't get merged to mainline (superseded by other branches, etc.) but which are of relevance to historical discussions on the lists.) There is one notable problem with CVS's handling of users without write access: they can't do "cvs add" to generate diffs with added files, though they can fake its local effects. I don't know whether svn fixes this. -- Joseph S. Myers jsm28@cam.ac.uk