From owner-freebsd-current@FreeBSD.ORG Wed Aug 18 13:24:34 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5B4A116A4CE for ; Wed, 18 Aug 2004 13:24:34 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id E798D43D41 for ; Wed, 18 Aug 2004 13:24:33 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i7IDMaYN052705; Wed, 18 Aug 2004 09:22:36 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i7IDMaVj052702; Wed, 18 Aug 2004 09:22:36 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Wed, 18 Aug 2004 09:22:36 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: drhodus@machdep.com In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: chris@behanna.org cc: current@freebsd.org Subject: Re: Public Access to Perforce? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2004 13:24:34 -0000 On Tue, 17 Aug 2004, David Rhodus wrote: > With the perforce trees being hidden away without public access to the > changes, this makes the FreeBSD project no longer an open source > project. That comment seems to be in stark contrast to reality. One of the most important goals in using Perforce to supplement CVS has been to get developers to stop keeping weeks or months of "in progress" changes solely on their notebook or workstation, and to increase collaboration opportunities among developers. Previously, developers would maintain large oustanding change sets on local machines as they developed features that were too "in progress" to merge to the main tree. This presented a risk to the project: by not maintaining this source on backed up systems, the chances of accidental deletion or loss, theft, crash, etc, were unsettlingly high. By providing access to a Perforce repository for personal or small project use, we've allowed developers to move personal development off of local and potentially unreliable systems onto a centrally manged "work in progress" server with revision control. If this weren't enough, the benefits of having three-way merging to better maintain and update "in progress" work with local revision control have improved efficiency and collaboration. As already pointed out, most if not all of the interesting "in progress" work in Perforce is regularly and mechanically exported as patch sets or via cvsup by the developers, something they can now do much more easily now than they could before. Most of the major group work going on in Perforce is exported via cvsup10 (TrustedBSD, etc). In addition, many developers post regular patch sets of the remaining work (SMPng, ...) to mailing lists or personal/project web sites. For example, instead of hosting the TrustedBSD work on an independent CVS server and having to maintain separate infrastructure, the TrustedBSD work is hosted on the FreeBSD Perforce server, making its source trees accessible via FreeBSD's cvsup infrastructure. When you subscribe to the TrustedBSD CVS list, you actually get a feed of the Perforce change sets from the TrustedBSD section of the FreeBSD Perforce repository. I think you'd have to work fairly hard to find open source projects that have no ouststanding local patch sets of as-yet uncommitted and experimental changes; by providing a central infrastructure to manage this, we're helping developers to avoid loss and collaborate better/more. Local and experimental changes are a necessary part of the development process for any reasonably large project, as the software mainline requires greater stability than the stability of every work in progress. CVS is notoriously poor at providing for this sort of branched development capability; while I know there's interest in other open source revision control systems to play the role Perforce is currently playing, attempts to import the FreeBSD revision history into other open source systems have generally failed due to the volume of changes and history present in the FreeBSD project. Undoubtably, people will keep trying until an open source revision control product is up to it. The unavailability of the perforce.freebsd.org web site is due to bugs in the older version of the Perforce web server, and that the software has not yet been upgraded. Hopefully that will be fixed soon, as that site was beneficial to everyone. However, I'm having trouble thinking of much or any on-going work in Perforce that doesn't get merged rapidly or made available via other means. If there's specific work you are interested in that isn't exported, I can make it available to you easily. I believe the general purpose submit list is also subscribable, although the volume of local changes is extremely high due to their "in progress" nature. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research