From owner-freebsd-current@FreeBSD.ORG Mon Mar 8 00:54:54 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AFF311065670; Mon, 8 Mar 2010 00:54:54 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 5003B8FC17; Mon, 8 Mar 2010 00:54:54 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o280mhAt065321; Sun, 7 Mar 2010 17:48:44 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sun, 07 Mar 2010 17:49:06 -0700 (MST) Message-Id: <20100307.174906.122313684076180456.imp@bsdimp.com> To: obrien@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <20100308000203.GA70486@dragon.NUXI.org> References: <20100307054423.GE70613@dragon.NUXI.org> <20100307.144904.1125936742922092260.imp@bsdimp.com> <20100308000203.GA70486@dragon.NUXI.org> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: phk@phk.freebsd.dk, freebsd-current@FreeBSD.org, rwatson@FreeBSD.org, ddkprog@yahoo.com Subject: Re: propose: all arch move into a separate dir X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Mon, 08 Mar 2010 00:54:54 -0000 In message: <20100308000203.GA70486@dragon.NUXI.org> "David O'Brien" writes: : On Sun, Mar 07, 2010 at 02:49:04PM -0700, M. Warner Losh wrote: : > In message: <20100307054423.GE70613@dragon.NUXI.org> : > "David O'Brien" writes: : > : On Fri, Mar 05, 2010 at 09:41:40AM +0000, Robert Watson wrote: : > : > On Fri, 5 Mar 2010, Poul-Henning Kamp wrote: : > : >> In message , Robert : > : >> Watso n writes: : > : >>> Doing that kind of rearrangement [...] would be a nightmare for anyone : > : >>> with large [...] patches, so I'd say we could pretty much rule that out : > : >>> outright. : > : >> : > : >> I would say that we should do it occasionally, to encourage these : > : >> FreeBSD users to contribute as many of their local changes back to : > : >> the project, as possible :-) : > : > : > : > Absolutely -- and rearranging a tree is a good way to invalidate : > : > all those patches as well :-). : > : : > : No, not it isn't. Provide a script to convert path's in the diff. : > : This is what $LARGE_FREEBSD_USER did when it rearranged it source tree. : > : > You are joking, right? This would be a nightmare for people that : > integrate early and often. : : : No I am not joking. I was responding to the point that a large patch : (that is a the output of running '$SCM diff') can be easily modified to : match a new directory layout. Thus patches in GNATS aren't "useless". It seems like it would be a nightmare for anybody tracking the system on a regular basis. : I'm not sure what operation you are specifically speaking to . But, if : FreeBSD were to move the CPU directories under 'arch/', at $WORK we would : do: : : cd sys : mkdir arch : svn add arch : svn mv {list of dirs} arch : svn ci : : and be done with it. Branches would merge that change - get a trivial : tree conflict, resolve it - and move on with life. And everybody who was tracking FreeBSD with their own changes would have to scramble. It wouldn't be trivial by any stretch of the imagination. The project is much larger than svn, and svn doesn't lend itself well to having external agents track it. : I would expect folks working in project branches to do the same. : : For merging changes from FreeBSD HEAD to FreeBSD stable - that is : trivial: : : cd sys : svn merge -c $GRN ^/head/sys/arch/amd64 amd64 : svn ci : : Subversion makes this a lot easier than CVS did. Just because the task is doable with svn, where it was impossible with CVS doesn't mean there wouldn't be a significant amount of pain to the folks using FreeBSD. It is cool that Juniper kinda has it worked out, but even there I'm skeptical about your claims. Especially since Juniper imports source rarely, where as other firms do it more often, and there'd be more pain for them. Warner