Date: Fri, 12 Jan 2001 14:34:09 -0800 From: Peter Wemm <peter@netplex.com.au> To: Trevor Johnson <trevor@jpj.net> Cc: Satoshi - Ports Wraith - Asami <asami@FreeBSD.ORG>, Will Andrews <will@physics.purdue.edu>, ports@FreeBSD.ORG, cvs@FreeBSD.ORG Subject: Re: overzealous cleaning of Attics in ports tree Message-ID: <200101122234.f0CMY9Q78574@mobile.wemm.org> In-Reply-To: <Pine.BSI.4.30.0101121134001.24868-100000@blues.jpj.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Trevor Johnson wrote: > > This is customary in the ports tree. As you may have seen in the > > past, the ports tree will undergo a periodic Attic cleansing. > > I never noticed it before. I suppose I haven't been keeping a copy of the > repository long enough, or I didn't watch cvsup carefully enough. I don't > see it mentioned in the Porter's Handbook, nor the Committer's Guide. We just have not done it for a while. We used to do it about every 3 months at one stage. > > There will be way too many dead files lying about otherwise. > > It costs me five cents to store the entire FreeBSD repo on a CD-R. Over > time, the cost of disks and tapes has (doubtless with some exceptions) > decreased. I have the impression that most people do not keep a full copy > of the repository, only the checked-out sources or a release CD-ROM. > Supposing that's true, only a few people store the dead files. 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. > > (By the way, the reason why I am so adamant about having repo-copies > > done when a replacement port enters a tree is precisely because of > > this.) > > Sometimes files can be sent to an Attic, yet no replacement is made. > Such files can still have value. For instance, the AUIS port was sent to > the Attic in October of 1999 because it would only compile in a.out > format. IMO the files could still be useful. For instance, someone might > want to compile it under FreeBSD 2.x and make the binaries available. I > know that porters aren't officially supposed to support 2.x (sometimes I > wish that applied to 3.x as well ;) ) but the minimal support of keeping > old files around--so someone can check out the ports tree as it was in the > past--is of value IMO. 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. > > That said, it seems like indeed Peter got a little overzealous. I > > thought we were supposed to only delete files that have been in the > > Attic for some time, not all Attics. > > I think my examples show that the length of time since a file went to an > Attic is not necessarily a valid metric. I ask you to change the policy > and restore the files which have no replacement. Again, I am willing to > help. 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. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 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?200101122234.f0CMY9Q78574>