> On Wed, Dec 30, 2020 at 2:31 PM Rodney W. Grimes <free...@gndrsh.dnsmgr.net> > wrote: > > > > On Wed, Dec 30, 2020 at 5:13 AM Rodney W. Grimes < > > free...@gndrsh.dnsmgr.net> > > > wrote: > > > > > > > > On Tue, Dec 29, 2020 at 04:18:07PM -0800, Rodney W. Grimes wrote: > > > > > > > The branch main has been updated by gjb: > > > > > > > > > > > > > > URL: > > > > > > https://cgit.FreeBSD.org/src/commit/?id=70e64ba4494190e64ab8faa04d744182d420c275 > > > > > > > > > > > > > > commit 70e64ba4494190e64ab8faa04d744182d420c275 > > > > > > > Author: Glen Barber <g...@freebsd.org> > > > > > > > AuthorDate: 2020-12-29 14:34:05 +0000 > > > > > > > Commit: Glen Barber <g...@freebsd.org> > > > > > > > CommitDate: 2020-12-29 14:40:28 +0000 > > > > > > > > > > > > > > release.sh: Update GITROOT URL > > > > > > > > > > > > > > Hard-code the GITROOT for the ports tree to use cgit-beta > > > > > > > until the ports repository is converted. > > > > > > > > > > > > > > While here, remove $FreeBSD$ RCS IDs. > > > > > > > > > > > > So how do I know what version of some file I am looking at > > > > > > once it has been dis-associated from a git clone? > > > > > > > > > > > > > > > > You can't. Git does not expand the tags. > > > > > > > > And no new mechanism in place to replace it? So, we have > > > > no versioning of files in the final product any more? > > > > > > > > > > No. We will not. > > > > That I take a very hard line against, that is IMHO a very big mistake. > > > > Your opinion has been noted. > > > > > > Sad, very very sad :-(. This may cause some down streams, > > > > other than me, some very serious heart ache. > > > > > > > > > > Git provides tools to reduce that heart ache. You can get the same info, > > > but using different means using git's tools should you need to. > > > > See other mail to Ryan, those tools well not help with the issues > > of locally modified files and being able to figure out what base > > they started with. > > > > You describe a source code management nightmare that $FreeBSD$ might be > able to solve a subset of cases, but other methods will solve them better.
This is not a source code management nightmare, it is a traceability of production items, this "feature" has been in BSD since /bin/what was written to extract SCCS id's out of binary files. That got broken cause we stoped putting them in, but the strings of $FreeBSD$ have always been in the binaries. This gives traceability. > > > > > > > > > Is there some new mechanism that can give me the cadence of > > > > > > say, /etc/pkg/FreeBSD.conf once its FreBSD ID is riped out? > > > > > > > > > > > > Also if $FreeBSD$ needs to be removed, can we please just do > > > > > > it in one massive tree wide commit rather than have this > > > > > > random piece wise needless noise in 1000's of commits? > > > > > > > > > > > > > > > > Please, no. There is no benefit to prune these in one fell swoop as > > > > > opposed to, for example, bumping Copyright dates. > > > > > > > > Well have to disagree on that. > > > > > > > > a) If it is removed in one fell swoop it can also probably > > > > be undone in one fell swoop too. > > > > > > > > > > It won't ever be undone, so this is irrelevant. > > > > I would be careful with any claim of never. > > > > I am. It's an extremely poor fit to git, has extreme resistance in git > upstream and the available git support is too limited to be useful. Big > effort, low reward item in a volunteer project generally means it won't > happen when there's other workarounds that are simpler and easier. So basically anything that git doesnt fit is now gone.. *sigh* > > > > b) It concentrates the change in 1 commit that does NOT > > > > ever need to be MFC'ed. > > > > > > > > > > That causes merge conflicts for everybody for years. The cost here is too > > > high. > > > > Again, please, enlighten me how a 1 line +- delta in a file is going to > > cause any merge conflict outside of +-3 lines from that line? These > > strings are VERY well located and in areas that should be very rarely > > touched. Very different than things like large white space clean up. > > > > Let's do some math. We have about 10k commits on a stable branch, give or > take. My experience with MFCing suggests that 5% of these will have a merge > conflict that needs to be resolved. Each one of these conflicts takes 5 > minutes to resolve because it breaks up the flow of the commits, etc. So > ~500 commits for ~5 minutes is ~40 hours. We've just wasted an entire week > of developer time for doing it all at once, vs almost 0 for doing it > incrementally. Your math is not math if you claim that this delta would cause 5% conflicts. MOST MFC conflicts occur because of missing interveing commits. You still have not explained how a 1 line delta removing a line is likely to cause any conflict at all, and I continue to assert it is very unlikely to as this 1 line is almost always in other lines that are very very rarely if ever changed. > > > > c) It'll quickly get us to the damage that is done by > > > > the loss of this information from the released binary > > > > product so repairs may begin. > > > > > > > > > > We can begin repairs w/o doing this. 99% of these never end up in > > binaries > > > anyway. > > > > Oh, now thats false... simple test: > > find /bin | xargs grep -l \$FreeBSD: | wc > > find /bin | wc > > > > 44/45 files on my 12.1 system. > > > > As far as I recall it is more like 99% of our files HAVE these strings in > > them. > > > > On my system, the numbers are quite different: > % find /*bin /usr/*bin -type f | xargs grep -la '$FreeBSD:' | wc > 4 4 64 > 3:14pm rebo:[245]> find /*bin /usr/*bin -type f | wc > 1032 1032 16791 > > And all 4 binaries are from 2016 and appear to be 'stale' leftovers. My guess would be your system is NOT from a production release of FreeBSD, probably compiled with a STRIP_FBSDID defined. I checked /bin on 11.2, 12.0 and 12.1 same results, all but 2 files. > > > > d) It'll shorten 1000's of commit messages by the lines: > > > > While here, remove $FreeBSD$ RCS IDs. > > > > > > > > > > Who cares? I mean, this is not an issue at all. > > > > > > Like I've said: there's a real cost to doing this, and the benefits from > > > doing this are quite small. As someone that's had to deal for years with > > > partial merges of sweeping commits, please listen when I say that they > > > always cause unintended pain due to their size. > > > > You can repeat yourself, but please give relavent factual cause on how > > this causes a merge conflict. > > > I have given numbers. We'd be wasting a week's time of all our developers, > give or take. I do not accept your WAG 5% as a realistic number. > > In most cases it would be a single line delete in an area of the > > file that is rarely touched. This is NOT like white space cleanup, > > macro renames, or other global scope changes. It is no worse than > > the SPDX tagging that was done, and if that had not been caught up > > in some work flow errors, would of been fine. > > > > There's value in the SPDX stuff, which we also did piecemeal, and which > also caused me grief when I MFC'd stuff because it was done in large > batches, and merged incrementally. Just because you see no value in FreeBSD, does not make it have no value. I would argue it has more value that SPDX. At least it is used programatically to create traceability in the production releases. > Warner -- Rod Grimes rgri...@freebsd.org _______________________________________________ dev-commits-src-main@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/dev-commits-src-main To unsubscribe, send any mail to "dev-commits-src-main-unsubscr...@freebsd.org"
