From owner-freebsd-arch@FreeBSD.ORG Tue Jul 3 15:27:39 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2F5B9106564A; Tue, 3 Jul 2012 15:27:39 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id F1D098FC08; Tue, 3 Jul 2012 15:27:38 +0000 (UTC) Received: from ralph.baldwin.cx (c-68-39-198-164.hsd1.de.comcast.net [68.39.198.164]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 6C030B985; Tue, 3 Jul 2012 11:27:38 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org Date: Tue, 3 Jul 2012 11:27:37 -0400 User-Agent: KMail/1.13.7 (FreeBSD/9.0-STABLE; KDE/4.7.4; amd64; ; ) References: <1340992732.19144.YahooMailClassic@web113501.mail.gq1.yahoo.com> <86mx3gdhlk.wl%gnn@neville-neil.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201207031127.37765.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 03 Jul 2012 11:27:38 -0400 (EDT) Cc: Doug Barton , arch@freebsd.org, gnn@freebsd.org, pfg@freebsd.org Subject: Re: svn commit: r237624 - in head: cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/llquantize cddl/contrib/opensolaris/lib/libdtrace/common sys/cddl/contrib/opensolaris/uts/common/dtrace sys/cddl/c... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 15:27:39 -0000 On Tuesday, July 03, 2012 10:55:11 AM Warner Losh wrote: > On Jul 3, 2012, at 8:50 AM, gnn@freebsd.org wrote: > > Again, moving to arch@ > > > > At Mon, 2 Jul 2012 14:09:31 -0700, > > > > David O'Brien wrote: > >> On Sun, Jul 01, 2012 at 08:32:41PM -0700, Doug Barton wrote: > >>> On 06/29/2012 10:58, Pedro Giffuni wrote: > >>>> Now .. David pointed out I am not respecting the code > >>>> provenance since I didn't add them to the opensolaris > >>>> vendor area, but these files are copyrighted Joyent > >>>> Inc (not even Illumos) so I cannot put them there > >>>> unless we create a new vendor for Joyent > >>> > >>> Creating a new vendor area would be the right solution, yes. > >> > >> I totally disagree -- it will cause a real pain merging. > >> > >> Think about it -- if we import a new code drop of uts/common/fs/zfs/*.c > >> into '^/vendor-sys/illumos', how do we merge that to HEAD? > >> > >> I don't believe 'svn merge -c ' will work because we already have a > >> different uts/common/fs/zfs/*.c from ^/vendor-sys/opensolaris. > >> > >> I think we either need to just call Illumos OpenSolaris for these > >> purposes, or 'svn move opensolaris illumos'. > >> > >> I think this needs to be discussed with the Repo Meisters. > > > > I actually agree with Doug here, but not strongly, I'd prefer to be > > better educated about this topic. Do our Repo Meisters read arch@? > > I agree with Doug as well. I think that transitioning from one vendor tree > to the other is the right thing to do. Unless we have good, concrete > reasons not to do this, I think the default assumption should be this is a > good idea. > > I believe that svn merge -c XXX will work because of how mergenotes work, > but I'd appreciate confirmation from our repo masters. I believe this will work fine. svn merge is a bit of a glorified "diff | patch" so it just extracts the diff for change XXX and applies it (but with some extra checking with mergeinfo to see if XXX is already applied). I believe you could even do "normal" vendor merges (no -c XXX arg) from both places (though you might have to resolve conflicts), and svn will just maintain two pieces of mergeinfo, one for each source. Given that, I think it would be premature to remove the opensolaris vendor area, but that doing a copy and leaving both vendor areas available is appropriate for now. -- John Baldwin