Re: Time to remove sccs tags
- In reply to: Brooks Davis : "Re: Time to remove sccs tags"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Fri, 24 Nov 2023 22:00:00 UTC
OK. I've pushed a branch to github for commenting. https://github.com/bsdimp/freebsd/tree/sccs I've broken it up in a couple of ways. First, one commit per directory for the SCCS removal. I did this for Brooks to see if that's what he wanted. Then I have one final sccs removal commit for the whole tree for what I had to do by hand. I can recreate the first 12 by script (plus two fixups) Then I have a 'remove all the copyright strings prefixed by @(#) that were ifdef'd out' commit which also did minor touchup of files. I did this mostly by hand since there was just a smidge too much variation. And then a whole lot of automatic removal of sys/defs.h that had filtered through the prior removal of FreeBSD, sccs, and copyrights. This is 100% scripted with me spot checking the diffs for sanity. I'm looking for feedback on the changes, of course, but also on whether I should fold back the last two commits into the first dozen or so done by directory (total of about 35 commits)... Or should I break them up by directory as well. I'm leaning towards folding back all but the manual changes and doing it all per directory (so 12 commits plus the one manial). Once I get initial feedback, I'll either go with my lean (if there's none) or adjust course as needed. I plan to MFC these to stable/14 on a best effort basis (eg, if it doesn't apply, I'll skip that chunk, but otherwise git cherry-pick -x). I have no plans ot merge this back to 13. diffstat says for this whole series: 7893 files changed, 125 insertions(+), 18138 deletions(-) I'm plowing through a tinderbox build right now, but amd64 builds both world and kernel. Since changes like this tend to go stale quickly, I wanted to do these two steps in parallel (any breakage is trivially different, usually adding back a sys/cdefs.h include). Finally, I have a number of sys/cdefs.h changes queued as well. These are cleaning up that file. I plan on batching it with this set of changes so that there's only one 'rebuild everything' event for most people... That is, unless the sccs series turns into a long discussion... Comments? Warner On Tue, Nov 21, 2023 at 11:03 AM Brooks Davis <brooks@freebsd.org> wrote: > On Tue, Nov 21, 2023 at 09:12:48AM -0700, Warner Losh wrote: > > It's been 30 odd years since the last csrg release. They are no more. > > > > At this point I think we can safely remove the few sccs tags that remain > in > > the tree. The data will be there in git if we ever need it. > > > > Comments? > > Yes please. The history is there in there repo(s) and there's so much > blind copying where the context is entirely lost. > > From my perspective it would be nice to have fewer commits per-subtree > than with $FreeBSD removal. In recent spelunking I've found that for low > traffic sub-trees I'm seeing a full screen (~50 lines for me) or more of > those > logs before getting to commits with content changes due to inconsistent > formatting leading to multiple removal commits. > > -- Brooks >