From owner-freebsd-current Thu Jun 20 12:03:10 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA01631 for current-outgoing; Thu, 20 Jun 1996 12:03:10 -0700 (PDT) Received: from haywire.DIALix.COM (root@haywire.DIALix.COM [192.203.228.65]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA01622 for ; Thu, 20 Jun 1996 12:03:05 -0700 (PDT) Received: (from news@localhost) by haywire.DIALix.COM (8.7.5/8.7.3) id DAA19414 for freebsd-current@freebsd.org; Fri, 21 Jun 1996 03:03:01 +0800 (WST) X-Authentication-Warning: haywire.DIALix.COM: news set sender to usenet-request@haywire.dialix.com using -f Received: from GATEWAY by haywire.DIALix.COM with netnews for freebsd-current@freebsd.org (problems to: usenet@haywire.dialix.com) To: freebsd-current@freebsd.org Date: 20 Jun 1996 19:03:00 GMT From: peter@spinner.DIALix.COM (Peter Wemm) Message-ID: <4qc794$gvg$1@haywire.DIALix.COM> Organization: DIALix Services, Perth, Australia. References: Subject: Re: When gcc-2.7.2 hits ctm Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article , chuckr@Glue.umd.edu (Chuck Robey) writes: > On Thu, 20 Jun 1996, Andreas Klemm wrote: > >> On Wed, 19 Jun 1996, Chuck Robey wrote: >> > On Wed, 19 Jun 1996, Andreas Klemm wrote: >> >> > Andreas, EVERYONE who uses ctm gets all their updates by mail. I doubt >> > if .05 percent of ctm users can take a one day 25MB mailbomb. I sure >> > couldn't, the university doesn't give me that much room. >> >> Well isn't it your local FreeBSD box ... what does the university have >> to deal with it ... > > Andreas, I can see why you don't understand yet. Most of the users of > ctm are doing so because they don't have direct connections to the net. > Just like me, they have dial up connections, and have to rely on someone > else's host for connections, and someone else's rules concerning disk > usage. I can give a Gig of space, but my University account has a 7.5 MB > limit on it. I think that some folks will have higher limits, some > lower, but the key point is that the amount of space is not under their > control. No amount of planning is going to allow for a 25 megabyte mail > dump. > > That's why I suggested specifically killing the mailing of the gcc, and > allowing folks to separately ftp the ctm update of that one. No one > would lose synch with ctm, and everyone would just be responsible to do > their ftp aas soon as they can, to bring their systems current. A couple of quick notes... The way I read the mkCTM script as run on, it's set ctm_smail's "maximum delta size" of 3MB, meaning that if the delta is larger than 3MB it wont be sent. However, this is before encoding and since it's a 3:4 expansion, the maximum chunk of mail could be 4MB. Is this too large? Remember, we have some complete tree taggings coming up real soon with the 2.1.5 release, so there's some large deltas in the pipeline. And the gcc delta wont be 25MB at all if I have my way. The basic 'cvs import' will actually cause a 1.4MB expansion in the repository, and since ctm gzips the delta, that comes down to 370K. The base64 encoding expands it to about 500K. However, I'm not 100% sure about how the internal encoding of the rcs files is going to handle the import (which will be nearly 100% conflict because the vendor branch was broken before, but this would re-sync it) followed by the merge. There are very few rev 1.1.1 files left, so by the time it's all over, there may be a doubling of the delta size to nearly 740K (or 1MB encoded). -Peter