Date: 17 May 1996 07:43:41 -0500 From: "Richard Wackerbarth" <rkw@dataplex.net> To: "Michael Smith" <msmith@atrad.adelaide.edu.au> Cc: "FreeBSD Hackers" <hackers@FreeBSD.ORG> Subject: Re: Standard Shipping Containers Message-ID: <n1379803457.92277@Richard Wackerbarth>
next in thread | raw e-mail | index | archive | help
Michael Smith replies: > Richard Wackerbarth stands accused of saying: > > Here is what's broken: > > > > 1) For the new sup user to get started, sup has to download > > the entire source tree, even though the user already has most > > of it from the tarball or the CD. > > This is irrevocable. No it is not! Think of the CD as a backup tape. If you put the appropriate files on the CD, the user has EXACTLY the same thing he would have if he had backed up his "up and running" sup'ped tree. The next, or in this case first, time he updates, he retrieves ONLY the files that have since changed. > The tree on the CD is on a dead-end branch, and > can't trivially be bent back to either of the main threads without > a monster master update. Wrong! Compare the 1M src-2.1.0060C.gz file to the 28M A.gz file. The savings are obvious. > The proposal of putting the CVS repository on a/the CD is a much smarter idea. This would make it practical to check out part or all of the tree in a state ready to be updated. Not really. The CVS tree goes out of date faster than any other. As I see it, any tree on a CD is really just a "backup". Either you are willing to work with potentially out-of-date sources or you need to have the mechanism to use that backup as a starting point to minimize the size of the update required. What I am advocating is to create a unified distribution scheme so that the user can choose the most appropriate means of update. Also for most people, the CVS tree is a problem. Not only is it relatively difficult to learn to use, but it requires two (plus) copies of the source, the extracted copy and the cvs archive. This applies to EVERY file, even those that the user never changes. > What could be simpler? ctm is fine for people who want read-only > source, People who "tinker" with their source tree and then use sup to restore it are wasting valuable resources, bandwitch and "our" server's cpu time. Anyone who has enough space to store both a tree and the routines that they have modified should be treating the tree as read-only. How else are they going to generate the "diff"s? Remember that it does not require two copies of the tree. (See "lndir") > and are willing to carry it all. I agree that this is a weakness of the present ctm scheme. I am addressing it also. The scheme that I have in mind would allow the user to choose his own criteria for which portions of the tree he keeps. Right now, "mirror" is the only mechanism that allows this possibility. With sup you are forced into predefined categories and, as you point out, right now with ctm there is only one category, the whole source tree. > sup is much better for people who like to tinker with their tree. > > And consider this: if someone can't manage either ctm or sup, how > the f* do you expect them to do anything useful with the source? It's not a question of their ability. It is the ease of getting there. After all, if you cannot master "ed",(forget "vi", it's too friendly), how can you expect the user to configure a system? The same applies to the source. I would venture a guess that the vast majority of the users who obtain the source never submit enything back into the master tree. They may only want the source because "it's nice to have", or they may install a few changes, or build a custom kernel, but they don't write code to enhance the system. -- ...computers in the future may have only 1,000 vacuum tubes and weigh only 1/2 tons. -- Popular Mechanics, March 1949
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?n1379803457.92277>