From owner-svn-src-head@FreeBSD.ORG Thu Jan 7 11:32:30 2010 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB3A1106566B; Thu, 7 Jan 2010 11:32:30 +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 B26918FC14; Thu, 7 Jan 2010 11:32:30 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 60C0F46B38; Thu, 7 Jan 2010 06:32:30 -0500 (EST) Date: Thu, 7 Jan 2010 11:32:30 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Luigi Rizzo In-Reply-To: <20100104222323.GA49068@onelab2.iet.unipi.it> Message-ID: References: <201001041825.o04IPcXb043347@svn.freebsd.org> <20100104190024.GA47532@onelab2.iet.unipi.it> <517EF225-7EEB-4844-A0AD-019AD72F9403@freebsd.org> <20100104222323.GA49068@onelab2.iet.unipi.it> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Michael Tuexen Subject: Re: moving sctp to a separate directory ? (Re: svn commit: r201523 - head/sys/netinet) X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 11:32:31 -0000 On Mon, 4 Jan 2010, Luigi Rizzo wrote: > I also think that the name of the new directory or the exact percentage of > ipv4-ness or netinet-ness of the sctp* and tcp* and multicast* stuff is > irrelevant. Moving directories with svn is so easy that we should not worry > even if we need a couple of attempts to find a good name. This is simply not the case. It's easy to rename in the parent branch, but that rename is propagated poorly to children branches, where developers will have to manually reconstruct changes made to the old file and apply them by hand to the new file. It's even worse when things are propagated from one repository to another, as all of our downstream vendors do, importing them into some vast combination of {CVS, SVN, P4, git, ..}. Why create unnecessary work for everyone? Robert N M Watson Computer Laboratory University of Cambridge