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]

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