From owner-freebsd-current Tue Feb 26 18:48:42 2002 Delivered-To: freebsd-current@freebsd.org Received: from root.com (unknown [209.102.106.178]) by hub.freebsd.org (Postfix) with ESMTP id 433DF37B422; Tue, 26 Feb 2002 18:48:32 -0800 (PST) Received: (from dg@localhost) by root.com (8.11.2/8.11.2) id g1R2ksx22502; Tue, 26 Feb 2002 18:46:54 -0800 (PST) (envelope-from dg) Date: Tue, 26 Feb 2002 18:46:54 -0800 From: David Greenman To: Robert Watson Cc: current@FreeBSD.org Subject: Re: Discussion of guidelines for additional version control mechanisms (fwd) Message-ID: <20020226184654.B21520@nexus.root.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ; from rwatson@FreeBSD.org on Tue, Feb 26, 2002 at 04:53:32PM -0500 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG >In the past week, a number of comments have been made both for and against >additional version control mechanisms being used to supplement the FreeBSD >Project official CVS server. Proponents of additional mechanisms, such as It's my view that work that happens outside of our official CVS repo is private work no matter what source control system is used (or if one is used at all). It is always a problem for one developer to say "I've got changes to , so don't touch that part of the system." This might be justified for a very short period (measured in a few days at most), but anything longer term will almost certainly put off other developers that may wish to work in the same or related area. This isn't a new problem, either. We've had similar turf conflicts before that very much resembled the one at hand. So...What's that phrase? - "Either take a dump or get off the pot". Something like that. Developers need to develop in ways that their work gets out as soon as possible so that 1) Other developers can review the work as it happens, make comments - perhaps influencing the design at an early stage when it really needs to be, and 2) So that you don't end up with some buggy mega-commit that has so much stuff wound up in it that it's nearly impossible to isolate the bugs. Anyway, my point is that the Perforce repo itself isn't the problem. The problem is that people are maintaining private patch sets for long periods and making claims to the areas that their patches cover. Step-wise evolution is the only way to go in this distributed development model and in order to acheive this, private development trees need to be minimized as much as possible. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org President, TeraSolutions, Inc. - http://www.terasolutions.com President, Download Technologies, Inc. - http://www.downloadtech.com Pave the road of life with opportunities. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message