From owner-svn-src-head@FreeBSD.ORG Fri Jan 2 07:32:19 2009 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 A262B106566B for ; Fri, 2 Jan 2009 07:32:19 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with ESMTP id 0D54B8FC12 for ; Fri, 2 Jan 2009 07:32:19 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 23256 invoked by uid 399); 2 Jan 2009 07:32:18 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 2 Jan 2009 07:32:18 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <495DC301.2090700@FreeBSD.org> Date: Thu, 01 Jan 2009 23:32:17 -0800 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.18 (X11/20081128) MIME-Version: 1.0 To: Gavin Atkinson References: <200901011055.n01AtQaN052763@svn.freebsd.org> <20090101215930.P70386@ury.york.ac.uk> In-Reply-To: <20090101215930.P70386@ury.york.ac.uk> X-Enigmail-Version: 0.95.7 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r186677 - head/usr.sbin/mergemaster 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: Fri, 02 Jan 2009 07:32:19 -0000 Gavin Atkinson wrote: > On Thu, 1 Jan 2009, Doug Barton wrote: > >> Given that this is a situation that comes up very infrequently (usually >> only for a major version upgrade) > > This is no longer true: a side effect of having SVN exported to CVS is > that every time a branch is forked, the CVS ID is bumped, and as a > result is different between 7.0 and 7.1 even if the file itself isn't > changed. Thanks for that explanation. > As long as this is handled with -U, however, I'm not sure I see the need > for special handling. I'd love to see the -U otion as default, and a > pre-populated mtree database for it shipped with the releases, however. > This would go a long way towards making upgrading more user-friendly. I would not be supportive of -U as the default for reasons I've stated previously on numerous occasions. The idea of pre-installing an mtree database is interesting, but the problem is that it gets awkward when you compare virgin installs to upgrades (which don't touch /etc/ directly). If someone wants to work up patches to the release process I'd be happy to review them, but I have no idea what re@ would say to it. hth, Doug -- This .signature sanitized for your protection