From owner-freebsd-current@FreeBSD.ORG Wed Aug 18 15:33:08 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 AD1E916A4CF for ; Wed, 18 Aug 2004 15:33:08 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 088EE43D3F for ; Wed, 18 Aug 2004 15:33:08 +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 i7IFV7sf056820; Wed, 18 Aug 2004 11:31:07 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i7IFV6Tr056817; Wed, 18 Aug 2004 11:31:07 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Wed, 18 Aug 2004 11:31:06 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Richard Coleman In-Reply-To: <41236212.5070500@criticalmagic.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 15:33:08 -0000 On Wed, 18 Aug 2004, Richard Coleman wrote: > Very well said. And very useful since reading this helps me to > understand better what is going on behind the scenes. > > At some point in the future, it would be nice if this type of local > experimentation and the mainline were brought under the same > infrastructure (subversion/whatever). But I don't think there is any > hurry since the current setup doesn't appear to be an obstacle. Yeah, the trick is finding the right tool. The FreeBSD CVS repository is imported in full (pretty much), and updated in the Perforce repository every couple of minutes. Exporting to CVS is a bit harder because CVS has trouble representing many of the more complex branching notions efficiently (the cvsup export of perforce.freebsd.org for TrustedBSD is much larger than the storage for the Perforce version of the same). A first test for any open source replacement for CVS in the FreeBSD project is that it be able to import our current history and workload efficiently. I believe last time this was attempted with Subversion, the importer ran at least a month before the person trying it gave up :-). Once a piece of software has been found that can have the complete history imported and handle our iterative workload from CVS commits, then the question becomes whether our development strategies can be mapped effectively into its capabilities: i.e., use of tags and branches for release engineering, etc. We need to periodically reevaluate the choices; the next logical point to do that is probably the next Subversion release, since it seems to be a popular suggestion for an alternative. It's worth noting that the Linux community has run into much the same problem: currently, they're using BitKeeper, a similar commercial product, for much the same reasons. svk is another promising looking alternative, but no doubt there are many others. The limitations of CVS are well known, and fairly well understood, but revision control software (especially supporting highly parallel, high volume development) is up there with OS programming in complexity :-). And as with OS programming, you put your source history in your most stable version, not your development head with the latest experimental changes. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research > > Richard Coleman > rcoleman@criticalmagic.com > > Robert Watson wrote: > > 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 >