Date: 20 Jun 1996 21:41:46 GMT From: peter@spinner.DIALix.COM (Peter Wemm) To: freebsd-current@freebsd.org Subject: Re: tcl -- what's going on here. Message-ID: <4qcgiq$gvg$2@haywire.DIALix.COM> References: <1867.835165278@critter.tfs.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <199606191511.JAA05842@rocky.sri.mt.net>, nate@sri.MT.net (Nate Williams) writes: >> >> 3. It makes it easier for people to experiment with a never version >> >> on their own. >> > >> >Ports already allows for this. >> no. >> >> Try gcc for a prime example of how it doesn't work. > > Huh? There are lots of folks using the PGCC port. Also, it took me *two hours* to produce a bmake'd gcc-2.7.2 by hand given the existing tree and Makefiles. And along the way, I merged in *two* overlapping patches from Bruce Evans, and later scanned the gcc commits to see what had been missed. Later on, I revived the objective C and libobjc stuff that had been left out of the original makefiles. >> >> 4. It takes up LESS space. >> > >> >BS. The *first* version takes up less space, but for every version >> >afterwards it takes up *incredibly* more space. Every new import >> >effectively doubles the space, since there is probably < 10% overlap in >> >a uuencoded gzip file. >> >> du(1) our gcc versions to see if that holds water :-) > > I just did. It looks pretty good considering how many changes have been > we've made. > > root:/home/CVS/src/gnu/usr.bin/cc # du -s > 12530 . > > root:/usr/src/gnu/usr.bin/cc # du -s > 11534 . > > We're doing a darn good job of keeping things small. The CVS repository > is less than 10% larger with *ALL* of the revisions than the actual > source code. > > (Bad example, it actually encourages using CVS) Well, I'll also add some real numbers too for a 'major' change, since the versions in the repository are pretty minor differences (gcc-2.6.0 through 2.6.3). Going up to 2.7.2 (naturally) is a bigger hit, but it's *not* double. And the gcc in the tree is a special case because the vendor branch was screwed for gcc when the 2.6.1, 2.6.2 and 2.6.3 versions were spammed onto the top rather than imported - this causes all the files to *leave* the vendor branch and causes each delta to be twice as big as it should be. Even with that penalty, the update to 2.7.2 is quite reasonable... Some concrete numbers (I copied the repository on my machine and did some trial imports and generated a few ctm deltas to tie in that aspect): A "du -k" of the CVS repostitory for "cc" - Original: 12.4MB After 'cvs import' of needed pristine gcc-2.7.2 sources: 14.7MB (this is the diff from gcc-2.6.0+hacks -> gcc-2.7.2 on the vendor branch; 2.3MB) After folding changes onto the HEAD revision: 16.1MB (This takes the head from gcc-2.6.3+hacks -> gcc-2.7.3+hacks (including objc): 1.4MB). The total growth in the repository is 3.7MB, which is a 29.8% growth. The ctm delta from -current to just after the import is: 551KB; and when base64 encoded for email transmission: 746KB. The ctm delta from -current to after everything is finished is: 1.08MB; and when base64 encoded for mail: 1.47MB. In summary, the repository grows by 3.7MB, and the ctm'ers cop a 1.47MB email hit. The ctm load can be split so that it happens in two seperate stages, the import of 2.7.2 does not affect the build, so we could import then wait for the ctm deltas to go out, and 24 hours later complete it, causing two 750K deltas a day apart. The people ftping it would be up for less. My personal feeling is that the max emailed delta size should be dropped from 3MB to 1MB. Just for comparison, lets look at the option that ``takes up LESS space''.. First of all, the gcc-2.6.x stuff would be deleted from the HEAD, moving it to the Attic. So, CTM deletes the old files and sends whole new fresh copies to go into the Attic. So, we have about 12MB of delta to move.. When ctm does that, the delta (because it's internally gzipped) ends up at about 2.9MB, and when base64 encoded, it's expanded to 3.9MB of email to the ctm'ers *just to delete the old gcc-2.6*! And it would ge mailed, because it's just under the 3MB cutoff... Then, you expand the repository by adding gcc-2.7.2.tar.gz.uu (around 9.7MB) and (if it was mailed, it'd be 13.2MB of email). Then, to *build* it, it would cost around 25MB of disk space in your obj dir to extract the source, plus about 5MB of temporary files and objects. The only saving that I can see anywhere, is that the amount of space consumed by gcc in your checked out /usr/src tree, which would drop from 12MB to 10MB, but if you build it, you're far worse off... For those using CTM because they are not sitting on the end of a clear T1+ pipe to freefall and have to get this stuff somehow, that's 13MB+ of bad news.. Ever tried ftp'ing a 13MB delta into an account with a 5MB disk quota? Compared to some of the CTM'ers I'm lucky, I'm on the end of a permanent modem link and this stuff comes into a procmail filter that pipes it to ctm_rmail, but both machines recieving deltas broke and lost 1 and 4 deltas because of having 30+ simultanious sendmails bringing it and other stuff that had backlogged in parallel... > Nate -Peter
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4qcgiq$gvg$2>