Date: Wed, 4 Jul 2012 06:59:31 -0400 From: John Baldwin <jhb@freebsd.org> To: freebsd-arch@freebsd.org, obrien@freebsd.org Cc: arch@freebsd.org, gnn@freebsd.org, pfg@freebsd.org, Doug Barton <dougb@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... Message-ID: <201207040659.31330.jhb@freebsd.org> In-Reply-To: <20120703182118.GA70183@dragon.NUXI.org> References: <1340992732.19144.YahooMailClassic@web113501.mail.gq1.yahoo.com> <EDA571E5-8B1F-40F9-8222-B92BD3E2DCCA@bsdimp.com> <20120703182118.GA70183@dragon.NUXI.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday, July 03, 2012 02:21:19 PM David O'Brien wrote: > On Tue, Jul 03, 2012 at 08:55:11AM -0600, Warner Losh wrote: > > On Jul 3, 2012, at 8:50 AM, gnn@freebsd.org wrote: > > > 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. > > ... > > > > 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. > > FYI, > When I disagreed with Doug it was for a "new" vendor tree vs. a renamed > (moved) one. In other words I disagree with having two vendor trees. > > > I believe that svn merge -c XXX will work because of how mergenotes > > work, but I'd appreciate confirmation from our repo masters. > > Please see below. I'm almost sure it will not work in what would be > likely situation. I expect 'svn merge -c' will likely have svn telling > you it cannot find the previous revision. > > > I think that having the two different sources is a good thing, should > > OpenSolaris ever come back to live and be a viable source of imports. > > We need to keep that option open, > > We're never totally shut off from any option. Even if we > 'svn delete vendor/opensolaris' and then later want to do an import > from Oracle, we (or Repo Meisters) can resurrect it in the manner that > is best for that time. But leaving vendor/opensolaris alive now, > makes it too easy for someone to import there that isn't aware of > the issues. > > > unless doing so has a real, demonstrable harm. > > I set up a test repository to show what I am concerned of. > I used Figlet (/usr/ports/misc/figlet) as it had a fork when the > original author moved on. I then did an import as if the original > author returned to his own line of figlet. > > Roughly: > 1. Import figlet 2.2.1 into vendor/figlet > 2. Merge 2.2.1 to head/contrib/figlet > 3. Import figlet 2.2.2 into vendor/figlet > 4. Merge 2.2.2 to head/contrib/figlet > 5. Copy vendor/figlet to vendor/figlet-NG [fork] > 6. Import figlet 2.2.3 into vendor/figlet-NG > 7. Merge 2.2.3 to head/contrib/figlet > 8. Import figlet 2.2.4 into vendor/figlet [return of original author] > 9. Merge 2.2.4 to head/contrib/figlet > > This lead to > Summary of conflicts: > Text conflicts: 6 > Tree conflicts: 6 > > Which is the problem -- what do you do with the tree conflicts? > Tree conflicts are quite different from the usual textual conflicts. > > Please see > http://svnbook.red-bean.com/nightly/en/svn.tour.treeconflicts.html Note > the examples there are more simplistic than our situation. > > When the 2nd vendor does an new release and it is merged in, you'll get > another set of tree conflicts. > > One thing to keep in mind with SCM's more advanced than CVS is objects > are not the same just because their file names are the same. An object > has a clear ancestry. Just because I am "David O'Brien", doesn't mean > another "David O'Brien" of a different mother is just a newer version > of me. > > One way to deal with this is to use "merge --ignore-ancestry". > Please see > http://svnbook.red-bean.com/en/1.7/svn.branchmerge.advanced.html#svn.branch > merge.advanced.ancestry which directly talks to our situation. > > But, I really don't think we want to use --ignore-ancestry. Per the > docs, it disables merge tracking (svn:mergeinfo is not considered when > svn merge is determining what revisions to merge, nor is svn:mergeinfo > recorded to describe the merge). It turns the 'svn merge' into a more > textual 3-way diff + patch. And even if we were OK with this, we would > have a very hard time documenting and getting the word out to everyone > that should know about it. (i.e., every committer that ever wants to > bring in new Solaris-family technologies) > > The other way is essentially to 'svn delete' the tree conflicts in > head/vendor/figlet before doing the merge and let the merge put in > files of a totally different ancestry. Then when the same tree > conflicts occur again when importing from the other vendor we do > the same. So we wind up with a ping-pong of ancestry and one cannot > readily read the commit history of these files. > > Also note the textual conflicts where there should have been zero -- I > made no text changes within head/contrib/figlet. > > I'll attach the set of commands and the 'script out sh -x' run > of that so folks can first-hand test this. Actually, this appears to have worked very well. The switch from vendor/figlet to vendor/figlet-NG was seemless. The text conflicts are for files changed by both vendors, and the tree conflicts are for when vendor/figlet updates a file removed by an earlier import from vendor/figlet-NG. That is exactly the sort of situation that requires manual intervention to determine the right course of action (should we bring back the deleted file or leave it out). Once you have made that decision and fixed up the version of the file you want to use (or left it removed) you can use 'resolve --accept working' to resolve the tree conflict. Why don't you try resolving one tree conflict by removing the file and at least one other by resurrecting the vendor/figlet file, then create new versions on each vendor that add some trivial changes and merge them. I suspect you will only have to resolve the tree conflict once (and not on each import). -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201207040659.31330.jhb>