Date: Sat, 15 Feb 2020 22:34:53 +0100 From: Oliver Pinter <oliver.pntr@gmail.com> To: "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net> Cc: Kyle Evans <kevans@freebsd.org>, "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org>, Shawn Webb <shawn.webb@hardenedbsd.org> Subject: Re: Return of config files to ^/etc Message-ID: <CAPjTQNFVFCsZqGA_DCmOCf7MgVmN1TQ6kmao=NEsNRc7j8EaSQ@mail.gmail.com> In-Reply-To: <202002152113.01FLD4aX049216@gndrsh.dnsmgr.net> References: <CACNAnaFffLq_6s=cAfj1=opRKZi0wUfP0%2B1ZmbTjdQojJzx7oA@mail.gmail.com> <202002152113.01FLD4aX049216@gndrsh.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Saturday, February 15, 2020, Rodney W. Grimes < freebsd-rwg@gndrsh.dnsmgr.net> wrote: > > On Sat, Feb 15, 2020 at 1:36 PM Rodney W. Grimes > > <freebsd-rwg@gndrsh.dnsmgr.net> wrote: > > > > > > > On Sat, Feb 15, 2020 at 9:13 AM Shawn Webb < > shawn.webb@hardenedbsd.org> wrote: > > > > > > > > > > Hey Kyle, > > > > > > > > > > On Fri, Feb 14, 2020 at 04:42:15PM -0600, Kyle Evans wrote: > > > > > > Hello, > > > > > > > > > > > > I've organized a review[0] to return most config files back to > etc/. > > > > > > I read the review, I have issues I need to post in it, but at the > > > moment dont have write access to reviews.freebsd.org due to broken > > > https mangling by a captive portal. > > > > > > > I will certainly be waiting on plenty of feedback for this one. > > It is actually minor feedback, but more about methods than content. > > > > > Something that I've intentionally not pitched yet (to avoid > conflating > > > > major issues) is the possibility of MFC'ing the move back to > > > > stable/12. It's feasible, but requires more care and attention than > it > > > > does in head/. IIRC, when you attempt to merge an svn mv/cp to > another > > > > branch, svn will stage it as a copy from the version in head/ that > > > > lives at the destination. So, when you try to MFC a mv/cp, you're > > > > effectively MFC'ing all changes before it unless you take care to > > > > assess and, as needed, revert those in the final diff. > > > > > > > > I will volunteer to do this work if the move back happens, but I will > > > > raise that as a follow-up issue. I suspect that it will be desired if > > > > we do the move in head, to ease the pain of merging back to our most > > > > recent branch. > > > > > > I'll volunteer to help you do that work if that move should need > > > to happen. > > > > > > > Thanks- I appreciate that! =-) > > Did you just stick a pitch fork in my hay bail? :-) > > > > You may actually simplify the process if you use reverts to undo the > > > change in ^head and merge the reverts back, I think that *might* > > > just do the right things, but I would need to run some test cases. > > > > > > > I have a fear (completely unfounded- I make no claims that this is > > correct or has ever happened) that svn would do the completely wrong > > thing and try to restore the old version. > > Well isnt the "old version" what we want to get back to actually? Not et all. There will be possible changes in the files in the newer place too. Like eliminating an architecture or improving defaults. For getting clue about what has been moved from svn is fine, but reverting - as I think - is not. > > Procedure above may be a bit wrong. Revert in ^head, then to take > that back to a branch it existed in at time it was branch just revert > that same commit from the branch. That should end with the "change" > removed from both head and stable/12. > > But still some testing needs to be done. Last time I did major > surgery the biggest issues I ran into on a branch was improperly > recorded merge history that I had to fix first, then things more > or less just worked as expected. Hint: record only merge history > that is not with the diff that merged it is evil nasty crap! So > is merge history recorded with another commit that is not the > actual merge diff. And yes, I ran into both cases in the FreeBSD > repository. > > > > > The more I think about it, the more I suspect that most folks that > > want this would also want it to be MFC'd to eliminate the friction, so > > I'll do some inspection up-front to see if we'd really run into > > problems here. Fortunately, there's only one branch that we need to > > worry about this for that's only about one year old. I suspect we > > could get away with MFC'ing any stragglers up-front, as I don't recall > > any major groundbreaking stuff happening in etc/ since 12 > > branched...but my memory kinda sucks. > > I agree with the suspecion of wanting the MFC'd. > > > > > Thanks, > > > > Kyle Evans > > > > -- > Rod Grimes > rgrimes@freebsd.org > _______________________________________________ > freebsd-arch@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAPjTQNFVFCsZqGA_DCmOCf7MgVmN1TQ6kmao=NEsNRc7j8EaSQ>