Date: Sun, 14 Jan 2001 07:06:10 -0500 (EST) From: Trevor Johnson <trevor@jpj.net> To: Peter Wemm <peter@netplex.com.au> Cc: Satoshi - Ports Wraith - Asami <asami@FreeBSD.ORG>, Will Andrews <will@physics.purdue.edu>, <ports@FreeBSD.ORG> Subject: Re: overzealous cleaning of Attics in ports tree Message-ID: <Pine.BSI.4.30.0101140430470.25832-100000@blues.jpj.net> In-Reply-To: <200101122234.f0CMY9Q78574@mobile.wemm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> Space is not the issue. The problem is cvs. cvs update -d -P creates > a checked out tree, creates a CVS directory in each node, creates 3 files > in each directory, and then when it discovers that it was empty, it then > procedes to remove each file, rmdir the CVS node and work its way back > up the tree. I dont know if you run with -async filesystems, but this is > very expensive in disk IO (synchronous in non-softupdates) and elapsed > time. It easily takes 2 or 3 times as long to do a 'cvs update -d -P' > with all this cruft lying around. I'm used to it taking a long time and I accept that. I'm not used to it being broken, and that bothers me. I feel that you've decided for me that speed is more important than keeping information intact. I would prefer to be allowed to make the decision for myself. If I wanted speed at all costs, perhaps I would take your suggestion and use an asynchronous mount, or maybe an MFS. > Have you noticed that we include the ports tarball on CDROMs and the ftp > server? If somebody really wants to get an old port to build on a 2.x > system, they are *far* better off grabbing the ports tree from the release > in general. I noticed a statement from Jordan Hubbard that 3.5.1 will be the last 3.x release. I notice that porters are still asked to maintain compatibility with 3.x, but not 2.x. I infer that there was a "flag day" when porters were told that compatibility with 2.x was no longer required, and that that day was sometime after the 2.2.8 release. Assuming the porters' work in that interval had value, checking out the ports tree as it was on that day would be better, for someone running 2-STABLE, than using it as it was at the time of the release. I don't understand why you come to the opposite conclusion. Old releases of FreeBSD are treated as cruft too: a look at ftp://ftp.freesoftware.com/pub/FreeBSD/releases/i386/ turns up nothing earlier than 3.4, and when I went looking on FTP Search for 2.2.8, (only 25 months old) I only found three sites that carried it. > I have a copy of everything that was deleted sitting on freefall in a > .tar.gz. I really really do not want this cruft to go back into > /home/ncvs/ports, but as a compromise how about leaving it extracted > elsewhere? Perhaps even /home/ncvs/oldports ? That avoids the > wasted time multiplied by the number of cvs updates multiplied by the > number of developers, but still leaves it within reach IF necessary. I don't want to jump through hoops when dealing with removed files. In PR 24276, David Gilbert writes: In the XFree86-4 port as installed by distribution CDROMs, there are a number of patch files that have been deleted from the cvs tree without being put in the attic. Even with "*default delete" turned on in my supfile, patch-1 is not deleted and causes the XFree86-4 port build to fail. This is a result of the purge, isn't it? I am afraid that the same chaos will happen to all the checked-out port skeletons I've worked on and put aside in the past. To continue work on them, I'll have to spend time sorting out the mess. That time is more valuable to me than my computer's disk I/O time. I can do other things while I'm waiting for the computer. If I want to see the output of a CVS checkout or update, I can make a log file and read it at my own speed. I've made a similar tarball. It's 61,128 files and directories--about 158 MB without compression. I know it's a lot to ask, but I don't see how CVS can work properly in the ports tree without all this so-called cruft. With your compromise, if I did a "cvs rm" on Monday and wanted to undo it now, keeping the history, could I do so without a portmeister intervening? If not, please try to imagine that the ports collection has similar importance as the rest of FreeBSD, and treat it the same. Pretty please? -- Trevor Johnson http://jpj.net/~trevor/gpgkey.txt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSI.4.30.0101140430470.25832-100000>