From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 12 09:36:06 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8314716A4CE for ; Mon, 12 Jan 2004 09:36:06 -0800 (PST) Received: from grouse.mail.pas.earthlink.net (grouse.mail.pas.earthlink.net [207.217.120.116]) by mx1.FreeBSD.org (Postfix) with ESMTP id C338D43D49 for ; Mon, 12 Jan 2004 09:36:02 -0800 (PST) (envelope-from chris@behanna.org) Received: from user183.net446.oh.sprint-hsd.net ([65.40.131.183] helo=192.168.1.2) by grouse.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1Ag5yr-00024F-00 for hackers@freebsd.org; Mon, 12 Jan 2004 09:36:01 -0800 From: Chris BeHanna Organization: Western Pennsylvania Pizza Disposal Unit To: hackers@freebsd.org Date: Mon, 12 Jan 2004 12:35:59 -0500 User-Agent: KMail/1.5.4 References: <1073582974.37229.8.camel@herring.nlsystems.com> <20040108180552.GA17378@opiate.soulwax.net> In-Reply-To: <20040108180552.GA17378@opiate.soulwax.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401121235.59788.chris@behanna.org> Subject: Re: Where is FreeBSD going? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: chris@behanna.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2004 17:36:06 -0000 On Thursday 08 January 2004 13:05, Munish Chopra wrote: > On 2004-01-08 17:29 +0000, Doug Rabson wrote: > > [...] > > > The three main showstoppers for moving FreeBSD to subversion would be: > > > > 1. A replacement for cvsup. Probably quite doable using svnadmin > > dump and load. > > 2. Support for $FreeBSD$ - user-specified keywords are not supported > > and won't be until after svn-1.0 by the looks of things. > > 3. Converting the repository. This is a tricky one - I tried the > > current version of the migration scripts and they barfed and died > > pretty quickly. Still, I'm pretty sure that the svn developers > > are planning to fix most of those problems. From mailing-list > > archives, it appears that they are using our cvs tree as test > > material for the migration scripts. > > [...cvs2svn.py scheduled for 1.0...] What about "arch"? I have it installed, but $realjob has prevented me from looking at it. And, unless I misunderstand, Perforce is available for free for non-profits, and the client is a free download. Other than a desire to be "pure" and use open source exclusively, what objection is there to Perforce? (And even considering that desire, Perforce is built upon open source: RCS and BDB, if I understand correctly). Speaking as a former CVS repo-meister (for a company that evaporated out from under me), Perforce really is a better mousetrap. No more, "I updated in the middle of a commit" problem, because commits are transactional. No more "Oh, god, this merge sucks", because Perforce keeps track of what was merged when, and where. The latest versions rather painlessly support cross-branch merges, too (i.e., pulling changes from one branch to another without having to first push up to and pull down from a common ancestor). Triggers can be written to prevent inadvertent DoSes (p4 integ -I //depot/branch1/... //depot/branch2/...) and to do submit-time checks. Risks are more easily mitigated with branches, and pulling/pushing of selected changes is MUCH easier (no more need to generate and apply patches by hand). Generating weird-elmo hybrid mappings of the tree is also a snap, and the repo itself doesn't bloat as badly because P4 uses its database to keep track of where histories go, rather than actually physically copy a file to move it in the repo. CVS: cp /CVSROOT/foo/bar /CVSROOT/foo/baz cvs delete foo/bar cvs commit (but bar,v lives forever, if you want to keep the change history and/or if you ever want to check out an old tagged revision of the tree) Perforce: p4 integ -t foo/bar foo/baz p4 delete foo/bar p4 submit (foo/baz doesn't actually physically exist. P4 keeps a DB record that foo/baz points to foo/bar, and this operation is only visible in the branch in which it was done, until that branch is pushed up to its parent) With Perforce, no repo-meister intervention is needed. Add in the ability to use local proxies to cache frequently-fetched files and revisions, and you have a winner, IMHO. I'm starting to sound like a spokesman. I'm not--just a *very* satisfied user. -- Chris BeHanna Software Engineer (Remove "bogus" before responding.) chris@bogus.behanna.org Turning coffee into software since 1990.