From owner-freebsd-current@FreeBSD.ORG Sun Mar 7 20:51:23 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 759B01065672; Sun, 7 Mar 2010 20:51:23 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 4E1328FC19; Sun, 7 Mar 2010 20:51:23 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id E2A2E46B0D; Sun, 7 Mar 2010 15:51:22 -0500 (EST) Date: Sun, 7 Mar 2010 20:51:22 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: David O'Brien In-Reply-To: <20100307054423.GE70613@dragon.NUXI.org> Message-ID: References: <3620.1267780989@critter.freebsd.dk> <20100307054423.GE70613@dragon.NUXI.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Poul-Henning Kamp , freebsd-current@FreeBSD.org, paradox 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: Sun, 07 Mar 2010 20:51:23 -0000 On Sat, 6 Mar 2010, David O'Brien wrote: > 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. > > It was done by creating a copy of the CVS repo and moved files around. Old > releases stayed in the old repo, and new releases done from the new repo. > 'diff | fixpatch | patch -p0' were used to move code between sandboxes. Indeed, this is precisely the problem: rearranging the tree upstream means that you most likely can't use the revision control system to manage your local difference set downstream. Instead, you have to manually extract your local changes, rework them to match arbitrary upstream rearrangement, and re-apply them as a single changeset creating a discontinuity in your revision history. This in turn creates problems with annotate, log, backing out changes prior to the merge, etc. All the reasons we like to use revision control for significant work. What you describe may work OK(ish) if you have to do it once every 3-6 years as a single massive merge and you were planning to do it by hand anyway (CVS and patches). However, other downstream users (including our own development branches in Subversion, P4, etc) reasonably expect to be able to use contemporary tools to manage the merge on a more frequent basis. As I said before: this isn't a vote not to rearrange things once in a while, it's instead a caution to say: this has a significant cost beyond "svn mv" that has to be taken into account when making the decision, so we should only do it with significant forethought and where there is significant benefit. Robert N M Watson Computer Laboratory University of Cambridge