From owner-freebsd-hackers Thu Jan 16 10:36:21 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id KAA05258 for hackers-outgoing; Thu, 16 Jan 1997 10:36:21 -0800 (PST) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id KAA05253 for ; Thu, 16 Jan 1997 10:36:15 -0800 (PST) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.8.3/8.8.3) with ESMTP id KAA26440; Thu, 16 Jan 1997 10:36:06 -0800 (PST) Message-Id: <199701161836.KAA26440@austin.polstra.com> To: davidn@unique.usn.blaze.net.au (David Nugent) cc: freebsd-hackers@freebsd.org Subject: Re: Important new CVSup *server* release In-reply-to: Your message of "Thu, 16 Jan 1997 18:54:26 +1100." References: <199701160536.VAA22195@austin.polstra.com> Date: Thu, 16 Jan 1997 10:36:05 -0800 From: John Polstra Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi David, > Are you going to start building dynamically linked pre-compiled > binaries some time soon? You meantioned previously that cvsup was > now only dependant on the m3 libraries (which I dutifully installed > :-)), so I had assumed that sometime in the future you will be > building dynamically linked binaries, and therefore distributing > much smaller files. Heh. You're going to kick yourself when you read the answer, because I bet you already knew it: pkg_add cvsup-14.1.1.tgz :-). The FreeBSD packages collection has exactly what you want. You probably already know about it, but the packages are binaries that have been pre-built from the ports. They're available in ftp://ftp.freebsd.org/pub/FreeBSD/packages-current and ftp://ftp.freebsd.org/pub/FreeBSD/packages-2.2 Now for the bad news: Satoshi builds the packages whenever he sees that a port has been updated. I asked him to expedite building the cvsup-14.1.1 package, since it's kind of urgent. But it appears that he's been away from his mail for more than a day. So the package I referenced above doesn't actually exist yet. :-( Hopefully it'll appear before too much longer. > > I apologize for the fire drill. > > :-) Well, I really worry about this sort of thing. People have to have confidence that they can rely on this program. After all, they're entrusting 300+ MB of sources to it. My biggest concern is that there will be too many incidents like this one, to the point where people will start to think, "Hmm, this whole CVSup approach just tries to do too much. Maybe it's too fragile ..." I *thought* in my initial implementation that I was being really conservative in my assumptions about what could and could not reasonably happen to a CVS repository. Now I know better. Everything that can possibly be done to a CVS repository _will_ be done to it -- usually late at night by a committer who has just screwed up badly and desperately wants to undo the damage before anyone finds out about it. The other two sources of problems have been disk errors and remote cvs bloodbaths. Never a dull moment. I silently thank Justin Gibbs every day for persuading me early on to implement the automatic "fixup" mechanism. Because of it, there is no way (aside from hardware/kernel errors and gravity waves) that CVSup can ever deliver a corrupted file. John