> -------- > In message > <capyfy2cebkmnvuj6_mthfq3ql6tq5v0jjoz01ex82-2kwql...@mail.gmail.com> > , Ed Maste writes: > >On Thu, 14 Mar 2019 at 14:55, Rodney W. Grimes > > >Doing some archaeology, the first instance of a uuencoded file I can > >find is r1796, "Got rid of a couple of binary files by uuencoding. 49 > >more to go." There's no explanation of why the change was made. > > I am pretty sure that we discussed the question of binary files in > the tree on either core@ or hackers@ (not much difference back > then), but that probably predates the "Dont mount the projects mail > archives on /tmp/something" incident. It would of been hackers@, this would of not been a core discussion.
> The first versions of CTM used diff -e and ed(1) to transmit changes, > and that choked up on binary files. We didn't have patch in the > tree back then. patch has always been in the tree. https://github.com/sergev/4.4BSD-Lite2/tree/master/usr/src/usr.bin/patch > > I can't answer definitively if modern CTM has any such restrictions, > but I would not expect so, either way, it should not matter. Warner said in another reply it does not, but this should be listed in the decision criteral, with a "not effected or formally effected" state. > >> We should also note that if they are already in uuencode state > >> to leave them in uuencode state, or do we intened to convert > >> them on next commit, or ??? > > > >Good point, converting existing .uu files to binary is just > >unnecessary churn and is not recommended. If someone is going to make > >a change it can be done with the next update. > > Agreed. So is it leave them forever .uu, on next import/whatever bring in the binary and remove the .uu, Or ? > p...@freebsd.org | TCP/IP since RFC 956 -- Rod Grimes rgri...@freebsd.org _______________________________________________ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
