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...
John Baldwin
jhb at freebsd.org
Tue Jul 3 15:27:39 UTC 2012
On Tuesday, July 03, 2012 10:55:11 AM Warner Losh wrote:
> On Jul 3, 2012, at 8:50 AM, gnn at 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 <GRN>' 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
More information about the freebsd-arch
mailing list