Date: Tue, 25 Jun 2019 09:26:03 -0600 From: Warner Losh <imp@bsdimp.com> To: "Rodney W. Grimes" <rgrimes@freebsd.org> Cc: Warner Losh <imp@freebsd.org>, src-committers <src-committers@freebsd.org>, svn-src-all <svn-src-all@freebsd.org>, svn-src-head <svn-src-head@freebsd.org> Subject: Re: svn commit: r349352 - in head: etc/mtree include lib lib/libnandfs sbin sbin/camcontrol sbin/nandfs sbin/newfs_nandfs share/man/man4 share/man/man5 share/mk stand stand/arm/uboot stand/common stand... Message-ID: <CANCZdfpR2xaqHxOfy%2BhobhO4wuoi4hRSdVD78DpQgXDCLEa%2BhQ@mail.gmail.com> In-Reply-To: <201906251324.x5PDONUQ049600@gndrsh.dnsmgr.net> References: <CANCZdfobKcAjw5Z2u6H7hgZpWTvg5mY1Uz4Ls9MMv98F8LoBWg@mail.gmail.com> <201906251324.x5PDONUQ049600@gndrsh.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jun 25, 2019 at 7:24 AM Rodney W. Grimes <freebsd@gndrsh.dnsmgr.net> wrote: > > This commit accidentally reverted r349333, r349334, r349335, r349336, > > r349339, r349340, r349341 and r349342. I rebased after one of the make > > universes I did to proof this set and something must have gone wrong and > I > > lost these changes. I noticed while committing, but didn't hit ^C fast > > enough to prevent the damage it seems. > > > > I've reapplied those changes rather than revert this commit for two > > reasons: first, reverting commits that delete things has caused me > trouble > > in the past. Second, I judge that to be less repo-churn than doing the > > revert, then redoing the nand* removal. > > > > Time was of the essence, so I hope my snap-judgement was sound. My > > apologies both for the 'oops' and for any other fallout. > > Though this may of reduced repo churn it also broke any MFC > that may of been marked in those sets. I am not even sure > how one would untwist that maze. > > MFC original commit is going to leave your second commit as > wrongly avaliable commit, so that needs dealt with. > > MFC your reapply commit, which they have to get by noting these > commits as the new merge number. Again, leaving a danglying > merge avaliable commit > > MFC the original commit, your mangle commit, but only the > part that applies to there original commit, and the reapply > commit. This marks the mangle as merged, but does infact > leave the merge avail list for head correct. > > None of that is very pretty. There are some other options... > > > Anyway my main reason for writting is somehow we need to get out > of this "repo churn is expensive I must not revert!" mode of > operations. Reverts are almost always the correct way to clean > up a mistake, and it almost always leeds to other issues to > not revert and instead try to do some magic like what was > done here. > > It is also often a mistake to not exactly revert the original > commit, commit that, then commit any additional fix. Reverting > and making other changes in the same commit leads to problems > more often than it solves them. I do understand the tree might > not be in a buildable or correct state for a commit or two. > I think that you over-state the issue here. Wouldn't the issue be fixed for MFCs of the replayed commits by MFCing them twice? The first time the first commit with svn merge, and then the second commit with a svn merge --record-only? We could do the same --record-only trick with the NAND removal commit, since it will never be MFC'd. Since the number of commits is small, and the people that would be MFCing them are super experienced with svn, I think that wouldn't be an issue. Then for others, it won't show up as a possible merge candidate (though honestly, with the files affected, that bit of svn is rarely used, also mitigating the data anomaly). I made a conscious decision to minimize time to get the repo repaired from the damage of the one commit. Warner Regards, > Rod > > > Warner > > > > On Mon, Jun 24, 2019 at 10:50 PM Warner Losh <imp@freebsd.org> wrote: > > > > > Author: imp > > > Date: Tue Jun 25 04:50:09 2019 > > > New Revision: 349352 > > > URL: https://svnweb.freebsd.org/changeset/base/349352 > > > > > > Log: > > > Remove NAND and NANDFS support > > > > > > NANDFS has been broken for years. Remove it. The NAND drivers that > > > remain are for ancient parts that are no longer relevant. They are > > > polled, have terrible performance and just for ancient arm > > > hardware. NAND parts have evolved significantly from this early work > > > and little to none of it would be relevant should someone need to > > > update to support raw nand. This code has been off by default for > > > years and has violated the vnode protocol leading to panics since it > > > was committed. > > > > > > Numerous posts to arch@ and other locations have found no actual > users > > > for this software. > > > > > > Relnotes: Yes > > > No Objection From: arch@ > > > Differential Revision: https://reviews.freebsd.org/D20745 > > > ... > > -- > Rod Grimes > rgrimes@freebsd.org >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfpR2xaqHxOfy%2BhobhO4wuoi4hRSdVD78DpQgXDCLEa%2BhQ>